Issue 16 of [IN]Secure Magazine is available. Mirko Zorz interviewed me in this edition (Page 41). If you decide to read it, I'd be delighted to hear your thoughts and feedback. The magazine edition of the interview is much better looking and highly recommended (as are the other articles), but for the sake of convenience, the interview session is below.
Enterprises need to formulate high-level goals for application security efforts before implementing specific service lines. What are the key areas they have to cover in order to make their endeavor successful?
I agree. You've got to strategize high-level goals before deciding on specifics. Most businesses are not in the business of being secure. They are in the business of generating revenue, protecting their brand, and their intellectual property. Application security goals must derive from and support these business goals to promise risk reduction across the enterprise cheaply and effectively. Such promises in turn require specific implementations and processes such as hiring the right talent, laying the right framework, hooking security into the development lifecycles, training, metrics, and executive support.
Despite owning a plethora of software and hardware solutions, the critical asset to an organization is still the security professional who works with those acquisitions. How exactly important is the security team?
Talent is key. What good is an application scanner or code analyzer if you don't have professionals in your team who actually understand the results? The fastest way to lose credibility with the business is to employ individuals who cannot go beyond running assessment tools and exporting reports. The job of a security team in any organization is not to hire people who can point and click their way into running assessment tools, but to establish a world-class effort that serves the needs of the business. You do that by hiring subject matter experts. You do that by hiring talent that can impress the business and demonstrate tangible value and progress.
With the threat landscape constantly evolving and old issues still not resolved, the organization has to battle problems such as a lack of security awareness that bring in a myriad of complications. What is the right approach to take in order to battle difficulties one can't completely protect against?
That's a two-part question: how to deal with known issues, and how to keep up with the latest attack vectors. First, you've got to establish a process that aims to remove security gaps at the root. Training and awareness offers the best ROI in this regard: bugs that don't get created in the first place - imagine that! It is also vital to embed security into the development lifecycles of applications. However many organizations have trouble deciding where to begin. The solution is to assign efforts based on risk. Start by understanding what applications you own and what their business impact is. What type of data do these applications read and write? What is the business criticality of these applications? Once you have a good understanding of your application portfolio, it will be much easier to assign effort so you can focus clearly.
As for the second part of the question, the solution is to invest effort into research and development so you continue to understand how the latest attack vectors may target your software. Yet again, training and awareness wins in this regard. Set aside a budget to send your team to information security conferences and training programs so they can soak up new knowledge. Allow analysts to take some time out to investigate the latest attack techniques. Most hands on security professionals are scientists at heart - understand what makes them thrive and support their talent. Support their desire to learn new ways to break security controls. Finally, capture and communicate this knowledge to the business. For example, ensure your threat modeling attack libraries are up to date and reflect the latest attack vectors, that your code review and assessment methodologies are bleeding edge, and that you take time out to brief the architects and developers on what they need to know to keep up.
Although applications have the largest attack vector today, CSOs don't take this into account when strategizing security spending. What kind of issues can this bring in the near future?
I overwhelmingly agree - the security spend of many organizations is out of whack with the real threat landscape. I feel there are multiple reasons behind this situation, the most common reason being, in my personal opinion, that many individuals who have been hands on in the past remember and hold on to the notion of the network layer being the only big thing to worry about. I can sympathize with that view - if you rewind a couple of years, majority of the high impact attacks could be identified and blocked via network controls because the attack surface of applications was low compared to today's scenario where a typical enterprise level web application is comprised of millions of lines of custom code. Perhaps another reasoning for this situation is that solutions around application security do not provide the instant gratification of throwing in a few appliances to solve problems. Well, perhaps, I should take that back, there are a few web application firewall solutions in the form of appliances that are starting to be marketed that way, but that's the nature of marketing and I'll save my rant for another forum. Also, quite unfortunately, there are going to be more situations in the coming future where many security efforts will align with reality after learning the hard way - i.e. after an application related exposure has already taken place. That said, the onus is still on the security professionals and researchers - we need to do an even better job of demonstrating impact and educating decision makers on why a solid application security strategy is vital to any organization's overall security effort.
While having consultants come in and perform black box penetration audits of applications every year is more costly than investing in a solid SDLC process, many organizations still believe it to be the proper strategy. What should they take into consideration when making this decision?
Black-box penetration tests are useful, yet they are extremely expensive and ineffective when relied upon as an exclusive solution. Paraphrasing a colleague of mine, "Companies that solely on black-box assessments to guide their security efforts do something similar to having consultants come in, throw a grenade at them, and have the consultants close the door on their way out". Gary McGraw likens this situation to what he calls a "Badnessometer". Black-box assessments correlate to symptoms that reflect the level of trouble you may be in. The response shouldn't be to just fix the black-box assessment results, but to respond to the situation strategically, and ensure you are responding to and eliminating the root cause of your problems to make sure they do not re-occur.
The solution is to "push left". The ingredients of a typical application development cycle, from left to right, includes the requirements phase, followed by design, then implementation, test, and production. The more effort you put into implementing the right security controls at an earlier tollgate, the lesser it will cost you. For example, assume that a review of security controls during the design phase results in an architect having to re-engineer the authentication mechanism. Now, imagine if this issue was not caught during the design phase, but uncovered during an attack & penetration assessment after the application is in production. It is not trivial to re-engineer a product that is already in production. And it is extremely costly - multiple times costlier.
Black-box assessments, coupled with the right strategy, do have their place. Going back to Gary McGraw's point, they help uncover symptoms. These assessments can be used to further augment and enhance an existing security SDLC process. For example, if you are finding too many issues via black-box assessments during pre-production that you missed to uncover during design and test, then it is time to re-evaluate your SDLC process and approach.
Besides having an excellent technical background, the CSO has to be good at demonstrating a tangible impact of his actions to the management in order to justify security spending. This ability is becoming increasingly important and can take the focus off the main areas of security he should be working on. How can the CSO lighten this load?
Justifying security spend for application security is not difficult. In addition, application security efforts can have positive political side effects for the CSO and the security team. I'll tackle these two points separately. First, application security must tie into the overall IT risk strategy. Start with asking what the company's business goals are, and how you want to demonstrate value. Map these goals to efforts based on risk that will flow into specific tactics that can demonstrate ROI. For example, if your organization currently relies on yearly black-box assessments, calculate the cost of performing the assessments in addition to the cost of remediation. Compare the cost with progress you've made by evaluating the last two assessment results for the same application. Most likely, you will find that you have made little tangible progress in the form of risk reduction and that the remediation cost has been high. Now calculate the cost of investing in a "push left" scenario. Put these two scenarios side by side, and you'll have a solid case for ROI. The returns for a good application strategy are tremendous. The important thing is to continue to measure returns by formulating a good metrics program. Keep track of how security is helping business and technology improve, measure the drop of defects per lines of code, measure the amount of risk reduction. Show value. Demonstrate how your program is embedding security into the organization's DNA.
To my second point, a well thought out application security strategy can help the CSO politically. If you hire the right talent, and approach business and technology with the right attitude, i.e. to enable and not disable, you'll make a lot of new friends. Security departments often complain that the revenue generating business units view them with disapproval, yet the quest for application security is a fantastic opportunity for the security team to work closely with business. Do it right, and the business will love you for it. You will win their credibility and gratitude.
How important is threat modeling?
If you want to do application security right, you've got to invest in threat modeling. The goal of a threat model is to enumerate the malicious entity's goals even if the threats being enumerated have been mitigated. This helps the business, developers, architects, and security analysts understand the real world threats to their applications. Threat modeling should be initiated during the design phase of the application and it should be treated as a living document. As the application development process progresses, the threat model can be further enhanced so it is increasingly valuable. For example, a threat model created during the design phase can be further augmented to map to actual code review results to help developers and architects understand areas they need to improve on and areas where they are doing a good job. Threat modeling is a core component of the push-left strategy, so you eliminate defects as early as possible.
What recommendations would you give to a new organization that is just starting to build an application security strategy?
Once you've derived from your overall business and security goals, it's time to list specifics.
1. Talent and Framework. Hire the right talent and lay the framework: policies, requirements, best practices, and methodologies.
2. Kick start efforts on critical applications. Kick start your efforts on your critical applications: work with business and technology to help them understand the risks to their applications and what they can do to eliminate them as early as possible. Help them invest their by offering advise on their architecture level security controls and threat modeling. Give the development teams guidance on secure coding policies. Assess the code for security defects, followed by a penetration test before the application is turned over to production. Ensure proper application logging mechanisms are built in and monitored.
3. Application portfolio. Come up with a formula to calculate business impact of an application based on key questions. Rank the applications by impact, and assign effort. At this point, you may want to take regulatory requirements into account, most often based on the type of data handled.
4. Invest in training and awareness. The security team, business, and technology must have access to continuous security training. Calculate metrics from code review results to target security training to certain business units. After a code review assessment, get a few of the developers into a room and show them the impact of the vulnerabilities found. Work together to enhance the threat model and possibly fixing the defects. The goal is training, awareness, and knowledge transfer.
5. Metrics. Demonstrate value, for example, a graph showing defects per lines of code decrease within the span of the last few months. Demonstrate risk reduction per business unit which often leads to some healthy competition, and that's a good thing. Overall, you've got to show application risk reduction across the enterprise.
6. Stay cutting edge. Retain talent. Treat your team well. Understand the latest attack vectors. Invest in research. Communicate and support the business - they are your clients and they need your help.
