• Skip to main content
  • Skip to primary sidebar
  • Skip to footer

DevelopSec

  • Home
  • Podcast
  • Blog
  • Services
    • Secure Development Training
    • Advisory Services
    • Application Penetration Testing
    • Application Security and SDLC Program Review
  • Resources
  • About
  • Schedule a Call

AppSec

June 3, 2016 by James Jardine Leave a Comment

Understanding the “Why”

If I told you to adjust your seat before adjusting your mirror in your car, would you just do it? Just because I said so, or do you understand why there is a specific order? Most of us retain concepts better when we can understand them logically.

Developing applications requires a lot of moving pieces. An important piece in that process is implementing security controls to help protect the application, the company, and the users. In many organizations, security is heavily guided by an outside group, i.e.. the security group or 3rd party testers.

Looking at an external test, or even a test by an internal security team, often the result is a report containing findings. These findings typically include a recommendation to guide the application team in a direction to help reduce or mitigate the finding. In my experience, the recommendations tend to be pretty generic. For example, a username harvesting flaw may come with a recommendation to return the same message for both valid and invalid user names. In most cases, this is a valid recommendation as it is the reason for the flaw.

But Why? Why does it matter?

Working with application teams, it quickly becomes clear the level of understanding regarding security topics. The part that is often missing is the Why. Sure, the team can implement a generic message (using the username harvesting flaw above) and it may solve the finding. But does it solve the real issue? What are the chances that when you come back and test another app for this same development team that the flaw may exist somewhere else? When we take the time to really explain why this finding is a concern, how it can be abused, and start discussing ways to mitigate it, the team gets better. Push aside the “sky is falling” and take the time to understand the application and context.

As security professionals we focus too much on fixing a vulnerability. Don’t get me wrong, the vulnerability should be fixed, but we are too focused. Taking a step back allows us to see a better approach. It is much more than just identifying flaws. It is about getting the application teams to understand why they are flaws (not just because security said so) so they become a consideration in future development. This includes the entire application team, not just developers. Lets look at another example.

An Example

Let’s say that you have a change password form that doesn’t require the current password. As a security professional, your wheels are probably spinning. Thinking about issues like CSRF. From a development side, the typical response “Why do I need to input my password when I just did that to login to change my password?” While the change will most likely get made, because security said it had too, there is still a lack of understanding from the application team. If CSRF was your first reason, what if they have CSRF protections already in place? Do you have another reason? What about if the account is hijacked somehow, or a person sits at the user’s desk and they forgot to lock their PC? By explaining the reasoning behind the requirement, it starts to make sense and is better received. It dominos into a chance that the next project that is developed will take this into consideration.

When the business analysts sits down to write the next change password user story, it will be a part of it. Not because security said so, but because they understand the use case better and how to protect it.

If you are receiving test results, take the time to make sure you understand the findings and the WHY. It will help providing a learning objective as well as reduce the risk of not correcting the problem. Understand how the issue and remediation effects your application and users.

James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.

Originally posted at https://www.jardinesoftware.com

Filed Under: Uncategorized Tagged With: applicaitons, application security, AppSec, ba, developer, developer training, development, penetration testing, qa, secure development, security, security testing

March 22, 2016 by James Jardine Leave a Comment

Introduction to Penetration Testing for Application Teams

In this presentation, James Jardine focuses on educating application teams on what a penetration test is and how to extract the most value from it. Application teams learn how to participate in the engagement and better understand the report.

You can watch the recorded session at any time at: https://youtu.be/I1PukF8Glh0

https://youtu.be/I1PukF8Glh0

Filed Under: Uncategorized Tagged With: app sec, application security, AppSec, developer, developer awareness, pen testing, penetration testing, secure development, security, security testing, vulnerability, vulnerability assessment

February 26, 2016 by James Jardine Leave a Comment

Application Registry: Knowing Your Assets

If an auditor asked you what applications exist on your network, how accurate do you think your answer would be? Do you have a repository or registry of the applications your company maintains? A good application security program starts with knowing what you have. Without this knowledge it is very difficult to understand the risk the applications bring to the company.

Depending on the maturity of your application security program, the way that applications are registered can be very different. On the simplest side, this may be a basic spreadsheet. On the advanced side the registry may be a custom built, or commercial application with lots of bells and whistles. In either case, the central repository of applications gives important insight into what exists. The ability to search through all applications for specific data fields will be a really popular feature.

In addition to the application name, creating a profile can be very handy. Here a list of some common items that may be useful in the application registry:

  • Application name – The name of the application. If the application has any nicknames or known by anything else it may be useful to capture that as well.
  • Application Lead / Contact Information – The name of the contacts responsible for the application. If an audit is occurring, questions arise, or anything else comes up, who should be contacted regarding the application.
  • Short description – A short description about what the application does and what it is used for. This may include how roles are used and/or maintained.
  • Programming Language / Framework – What language is the application written in. For example, Java, .Net, Python, Ruby, etc. The version is also helpful to understand if the latest version is being used or what language security issues may be present. For the framework, is this MVC, Spring, WebForms, etc.
  • Third party components – Applications are commonly made up of many external components which may contain vulnerabilities at some point. Tracking these items can help identify which applications may be effected in the event a vulnerability is found in a component.
  • Data elements / classifications – What data is used by the application? Does the application store credit card data, health data, personal information? Record the sensitive information and classify the application based on the most sensitive data. Your company should have a data classification policy to assist with this.
  • Regulatory Compliance Requirements – Does the application fall under any regulatory requirements such as PCI or HIPAA?

The above items are not a complete list of fields, but should help get you started if you don’t have anything to this point. Remember that an application security program doesn’t mature overnight. It takes small steps to get where you really want to be. Starting with an application registry is a good first step to provide insight into the environment.

In future posts I will dig deeper into the information that can be tracked with the application registry. If you have other fields you track or know of any good applications to help track your applications please feel free to send them over.

Filed Under: General Tagged With: Application registry, application security, AppSec, Assets, developer security, security, security tracking

  • « Go to Previous Page
  • Go to page 1
  • Interim pages omitted …
  • Go to page 4
  • Go to page 5
  • Go to page 6

Primary Sidebar

Stay Informed

Sign up to receive email updates regarding current application security topics.

Contact Us:

Contact us today to see how we can help.
Contact Us

Footer

Company Profile

Are you tackling the challenge to integrate security into the development process? Application security can be a complex task and often … Read More... about Home

Resources

Podcasts
DevelopSec
Down the Security Rabbithole (#DTSR)

Blogs
DevelopSec
Jardine Software

Engage With Us

  • Email
  • GitHub
  • Twitter
  • YouTube

Contact Us

DevelopSec
1044 South Shores Rd.
Jacksonville, FL 32207

P: 904-638-5431
E: james@developsec.com



Privacy Policy

© Copyright 2018 Developsec · All Rights Reserved