Baking security in to our applications is just not an option anymore. The explosion of the number of applications within organizations, coupled with the constant breaches we hear about (and the many more we don’t) don’t allow room for complacency when it comes to securing your organization and customer data.
Yet CISOs and security managers still struggle to receive the support and buy-in for basic application security practices while developers are still making careless security mistakes, all because application security is still not being taken seriously enough.
One of the best ways of getting the organization’s support towards AppSec is coming to the board with a clear, measurable program in place. And even with an AppSec program in place, it’s difficult to know if you’re “doing it right.” Here we offer six points of attention any security practitioner either implementing or designing an application security program should heed.
No security expert has ever uttered the phrase ‘ignorance is bliss’ as it applies to securing organizations. The number one way to make sure your AppSec program fails is to not do a complete inventory of the software and applications owned and used at your organization. Without this inventory, there’s no way to know what data and end points aren’t fully secure.
One of the first keys to ensuring your AppSec program doesn’t fall on its feet is to gather a comprehensive index of not only the applications used and produced in your organization, but have also identified and documented the points of connection between the applications, including the security controls and check points.
Your inventory also requires you to understand which legacy systems and open source software and libraries could also be an important part of the data flow, and which need special attention in your AppSec program. Depending on the size of your organization this process can be done manually or automatically.
This article from Microsoft offers a deeper look at the application inventory process.
After you’ve identified all the applications in your organization, the next tip would be to evaluate their risks. Determining which applications are most critical to the organization and should have the highest security controls and which, if any, pose too high a risk for the organization will give you the insight you need to develop a well-defined blueprint for threat modeling.
The most effective way of evaluating risk is to set a risk rating for each of the applications you inventoried in the first step. Many organizations do this differently, and it’s important to choose the modeling system best suited for your organization. OWASP, for example, uses and recommends Microsoft’s threat modeling process due to its simplicity and easy adoption by each team in the Software Development LifeCycle (SDLC), which Microsoft itself has noted that it is the single most important factor in their security improvement program.
In the 2014 SANS survey on Application Security Programs and Practices, survey participants indicated that a lack of application security skills was the top inhibitor to the success of the programs. Where in past years the biggest barrier to a successful AppSec program has been receiving the buy-in and additional support of the organization’s decision makers, the tables have turned: the most difficult hurdle these days is having enough application security experts on hand.
Training your developers is one of the best ways to ensure a long-term, viable future for your application security program. As we know by know, developers historically had no hand in the security side of code and had the responsibility to deploy the most feature-packed software as quickly as possible – a way of deployment that doesn’t allow the type of testing and remediation efforts that come along with application security testing.
As Mark Curphey, OWASP’s original founder has said: “In the 80’s we wired the world with cables and in the 90’s we wired the world with the computer networks. Today we are wiring the world with the application. Having a skilled professional capable of designing, developing and deploying secure software is now critical to this evolving world.”
By linking their application security training with their current work on applications, developers get a solid understanding of the importance of vulnerabilities, why they need to fixed and most importantly, how to fix them properly – once and for all. As the SANS survey stated, “developers—and managers—need to be convinced that all of this is worth their time.”
We recommend you make the training sessions something developers can have a little fun with. Put yourself in the developer’s shoes: It’s not that they don’t want to code securely, it’s that it isn’t something that was really stressed in most developers education and experience. Most developers will want to code securely and by making the training and education more appealing to them, there’s a far greater chance of them actually changing their coding habits to be more secure.
Key to getting any initiative up and running is getting the right support from the right people. When it comes to application security, the way to get support is to align your security priorities with the businesses goals, and communicating that to the board.
Communicating the issues or potential risks in business terms puts security hand in hand with day-to-day operations and explains your programs relevance. Because in the end, security’s place in an organization is as a business enabler – not a hinder to doing business. Once you understand that, you can more easily communicate the risks of launching insecure applications and offer tangible ways to avoid those risks, as planned in your AppSec Program.
Aligning security with business objectives will also make it easier to get the necessary support and funding for developer training programs. Troy Hunt, for example, has said that “it often takes a breach for the ROI on developer training to be realized.” Get the business to understand the vitality of quality application security training for developers by determining the business risks posed by the the organizations “high-value” applications and you’re on your way to avoiding breaches in the first place.
If you aren’t implementing security throughout your SDLC, you’re already giving yourself a chance to fail.
By enforcing security controls within each of your SDLC phases, you’re helping ensure that not only will the end product be secure, but that the costs to fix security bugs will be significantly slashed. A study by the National Institute of Information Security and Gartner found that the cost of fixing an application security vulnerability during design or development costs 30-60 times less than if the same vulnerability is fixed during production. Those types of numbers will no doubt push your case in communicating the importance of baking in security to the C-Suite.
For a secure SDLC, it’s vital you choose the correct tools for the job. And if there’s one solution in particular that will help sustain a secure SDLC, it’s static code analysis (SCA). When correctly implemented within the SDLC, static code analysis will detect security bugs nearly instantly, giving developers a chance to fix their code well before its sent on to testing.
The SANS survey mentioned earlier also stated that “although bridging the gap between Infosec and development teams and getting developers to use static analysis testing effectively can take time and effort, it can also pay dividends by providing a much faster feedback loop.”
A strong static code analysis tool will be easily integrated into your existing tools throughout the build cycle for quicker and easier adoption. Putting the time and resources into effective tool training as well as the best set of security tools will allow your program to achieve high ROI.
For an easy-to-digest, entertaining presentation on securing the SDLC, check out this slide deck from OWASP AppSec DC 2012.
Just because you’ve followed the first 6 tips doesn’t mean you’re off the hook – not even close! The dynamically changing environment of application security will demand constant assessment and evaluation of the program you’ve put in place.
This is where KPIs (Key Performance Indicators) come in. As you come to a better understanding of your organization and its business goals, you’ll be able to map your security programs KPIs to the long-term goals of the business. The best types of assessments will provide context for your security activities and offer a plan for improvement
KPIs will differ from organization to organization, but what is important to keep in mind is that your points of measurements will strongly connect what you’re doing with your security program to your businesses long term goals.
For more on AppSec KPIs, check out this presentation by Deloitte.
Sign up today & never miss an update from the Checkmarx blog
Interested in trying CxSAST on your own code? You can now use Checkmarx's solution to scan uncompiled / unbuilt source code in 18 coding and scripting languages and identify the vulnerable lines of code. CxSAST will even find the best-fix locations for you and suggest the best remediation techniques. Sign up for your FREE trial now.
Checkmarx is now offering you the opportunity to see how CxSAST identifies application-layer vulnerabilities in real-time. Our in-house security experts will run the scan and demonstrate how the solution's queries can be tweaked as per your specific needs and requirements. Fill in your details and we'll schedule a FREE live demo with you.