I have so many topics and thoughts that I want to communicate on this blog. I could write for days on PCI-DSS; especially an exercise I recently lead to select a QSA for a professional services consulting engagement; not to be confused with a PCI-DSS compliance assessment. I have a load of thoughts about the current book I am reading by David Vose titled “Risk Analysis, A Quantitative Guide”. I still have not transferred my notes regarding Securosis’ “Business Justification for Data Security” paper to a blog post. BTW, Rich Mogull – congrats on the new born!
For this post I want to share some information about a professional development project I lead back in 2007 and 2008 for my employer that bridges application security and risk assessments.
When I first started working for my employer, I knew that I was going to be performing risk assessments. However, I thought most of my risk assessments were going to be more in the area of networking information security and data information security. Within a year of starting the job – I knew that application security and risk assessments were going to be a significant part of my job. So, because I was weak in the application security discipline, I added application security to my personal development plan in 2007; it is still there today. My quest for learning more about application security resulted in co-developing an application security assessment methodology for our employer as well as lead me to reviving the Columbus, OH OWASP Chapter.
The problem I faced in 2007 was that I was being assigned to more and more complex application development projects. Because I was not very skilled in the application security discipline, I could not perform effective risk assessments. For example, I struggled identifying meaningful vulnerabilities let alone being able to validate vulnerabilities without wasting another team member’s time. So, my manager allowed me and two higher skilled individuals on our team to sit down and document how they approach an application security risk assessment. Eventually, one of the two individuals left our company and went to go work for Amazon as one of their head application security professionals. The vacancy was short. We added another person to our team who came up through the application development ranks and provided the extra spark we needed to get the methodology from a straw-man to a usable product in late 2008.
Disclaimer 1: Our application security assessment methodology is not limited to just web applications. In large and/or complex environments – you do not have the luxury of dealing with just web platforms and simple backend databases. You will most likely be dealing with multiple applications, use cases, and business processes that span numerous technologies, languages and protocols.
There six high level concepts to this methodology. The first three concepts are straightforward and usually give you 80% of the information you need to facilitate a risk assessment. The last three concepts usually require more time and understanding. You will also notice how they all build upon one another – which should also reduce the number of information gathering activities. Let’s jump into them.
1. Information classification.
The very first thing we want to understand is what type of information is handled or exposed as part of this development effort. Is it public information or confidential information? Are we sharing information with a new application? Are we sharing information with an external business partner? Does this development effort allow for data to be modified? What is the business purpose of this information?
Let’s face it, for most vulnerabilities that can be exploited AND result in data loss – if we do not understand the value of the information – we cannot appropriately communicate the severity of the exposure (or lack thereof) to our business partners. I want to give a quick plug to the Securosis team on the information value concept. They dedicate a portion of their “Business Justification” white paper to information value and it is worth reading if you need a refresher on or are new to information value.
2. Use Cases.
The next area we want to have visibility into is use cases. Understanding the use cases is probably one of the most efficient ways to learn information about an application. Properly documented use cases should let you know who is using the application, what other applications the application under review interfaces with, data flow, business rules, and a ton of other information.
Do not underestimate the value of use cases. BTW, documented use cases should be a requirement within any project delivery methodology. If your organization does not have a defined project delivery methodology – you can find use case templates on the Internet. Make it one of *your* requirements in order to complete an application security assessment. Not only will you benefit – but more then likely the whole project team will benefit from it as well.
3. Application Architecture.
Application architecture can mean different things to different people to different organizations. To keep this high level – let’s stick with application architecture in the context of web applications and interfaces with other applications. If a web application: is the architecture appropriately tiered? Does the architecture result in the application interfacing with other applications or business partners where it could be inheriting risk of those applications? Does the data being handled have special architecture security requirements? There are dozens of other questions but you should get the point.
A simple example of where application architecture comes into play is PCI-DSS. In appendix F of the PCI-DSS requirements – you will notice that one of the first questions the QSA (auditor) is asked is whether scope of the assessment can be reduced due to network segmentation. I am sure you can think of some other business processes or information types where security requirements can significantly impact the application architecture (or find vulnerabilities within the existing application architecture).
4. Access management.
Simply put, how do we control access to the application and how does this application interface with other applications, databases, or services. I consider this security 101 stuff – but in an application security context. Also, even in companies with well defined security policies and mature security practices – do not think for even a quarter of a second that there is not someone trying to do more with less when it comes to shared IDs and passwords or using unauthorized user repositories for access management (local DB versus LDAP integration).
An additional thought that I would share on this topic is not taking for granted excessive rights a user might have for public data. An example that one of the co-developers of our methodology uses is that of an intranet application that allows all employees to view the cafeteria menu. This is essentially public information. However, we still need to have more stringent controls around who can modify the data lest we find ourselves reading that the main lunch course is “possum belly and grits” instead of a “muffaletta sandwich with olive salad”.
5. Code implementation.
This is a huge and important concept of which I can only scratch the surface as part of this blog post. For the OWASP folks out there – you know what this is. Do we have sound code development practices? Do we have security controls at all tiers of the application; including the most forgotten tier – the client tier? Do I have special data security requirements that need to be accounted for in my application code?
While this concept may be the most complex it is also a concept that separates the wheat from the chaff amongst application security professionals, information security professionals as well as security-minded developers. If you ask a self-proclaimed security professional or a self-proclaimed security-minded application developer what input validation or buffer overflows are and they miss the answer by a mile – red flag. Inspecting code and validating vulnerabilities is another topic worth mentioning in this post. I have been in the position where I ran a web application vulnerability scanner and raised red flags on SQL injection findings to the development team; only to find out that it was a false positive. I was personally embarrassed and professionally I felt that it made our profession look bad. It was a valuable lesson learned and continues to be something I reflect on from time to time to make sure my personal development plans are hitting the mark.
6. Operational Plans.
This concept is more about how an application team manages their application. Whether more in the context of the software development life cycle (SDLC) or day-to day operations – there are often points of vulnerability in this area that get overlooked. Some questions related to this concept may be: How do I control my source code, let alone access to it? Do I have adequate and appropriate logging within the application? Am I logging information I should not be? How do I provision and de-provision access to the application? How is production support handled?
It is too easy to forget about the day-to-day operations of an application especially for projects where the application is brand new. The way I look at it, this is the perfect time to make sure the requirements are established up front as well as implemented – versus being reactive post implementation. For existing applications – especially application that never received a security review or a recent security review – here is the reality: The threat landscape and regulatory landscape is ever changing. Just because there were not security requirements five years ago or even 20+ years ago (yes, we have an application that old) does not mean security controls should not be implemented today.
So there you have it folks, a very general approach to performing an application security assessment. Of course, once you flush out some risk issues, you can assess them for risk using your favorite risk assessment methodology.
If this application security assessment methodology appeals to you – let me know. Better yet – if what general information I have shared is lacking – please let me know. Either point me in the direction of a better methodology or give me some insight to help make it better. One final note, I do have intentions of getting my employer’s permission to give a more detailed presentation of our application security assessment methodology at a future Columbus, OH OWASP Chapter meeting.
Thanks for reading my blog – have an awesome day!
