Pillars of Application Security

You realize you have a problem within your application environment, you’ve convinced business & management to do something and now your job is to respond with building an application security program.

The hardest part of any good building project is laying a foundation and understanding what that foundation means. If you lay a square foundation, but attempt to build a triangular building, well sure, the foundation can support the building, but the foundation is either going to be too big or too small. Both have inherent issues. Defining the pillars of an App Security Program is much like laying the foundation. What do the pillars require? How many different ways do they need to support the app security program? Do I want a few big pillars from a high level or a few small narrowly scoped pillars?

Foundational Planning

Continuing the building metaphor with so many possibilities for different foundations, designing an app security program is much like being an architect, but it’s also a salesman. Your job is to figure out what the best foundation is for your program, if you make the wrong choice and you choose too many pillars that are narrow in scope, your security program may not take on enough, leading to an insecure state, or it might take on too much and with so many narrowly defined pillars; the top heavy beast that is your security program might crash down, or a pillar might crack.
If you have too few but large pillars, your program might grow too big and you’ll be forced to split a pillar or have another pillar into the program which could be hard when things are well defined.

Before you can lay the foundation to the security program, you need to spend some time thinking and coming up for a vision within your security program. Unfortunately, this cannot be done in a vacuum. If you’re building a security program, you’re probably new to the role (I’ll talk about expanding and changing a security program later). Spend some time learning about your role within the team, within the organization, hopefully you’ve got some company to build the program with, if you don’t however talk to people. Talk to your manager - they’ll have one perspective on something, talk to your manager’s manager - they’ll have a different perspective. Talk internally to your team (even if you don’t share a role with anyone, learn how your colleagues see you and what they expect out of a program, lastly talk cross functional to learn and see how and what a role really is. The program you define and build will ultimately define and build you, and your role. If you have an information security team within the organization, they may be a good resource or they may not be it’s hard to say. At my organization, we have an information security team that defines the whole security program for the entire organization, however there is more than plenty of room to define an app security program for a sub organization within the larger scope of the whole organization.

Often times, Information Security units don’t have the resources, the time or the skills, to get detailed level into application security, they’ll identify problems from external scanning sure, but an effective application security program is about releasing a secure application before information security can find out about any security issues. By the time information security can find out about something, an attacker or an adversary can also find out, so there is room for Information Security to exist & for an app security program to be successful and compliment what the information security team is doing, and there is nothing wrong with that. Hopefully at the end of the day, the overall product is a much more secure application. An application security program brings highly specialized skills to the table, and needs to understand developers and developmental security whereas information security is a very broad outlook for the whole organization. However, if your organization doesn’t have an informational security team but has applications, don’t fret it, start with the app security program.

The Pillars

The pillars of your application security indicate the founding principals upon which you’ll build the program, the next step of the program is to determine a founding charter, much like the constitution was driven by some basic founding principals, your charter will be driven by some founding pillars.

Now you have an idea of where you want your program to go and what you want it to look like. You’ve made decisions about is it going to be just an application security program, or is it going to be an enterprise wide program, do you include just applications, or applications and servers, when considering applications, are you going to include vendor applications, or just apps built in house? Hopefully, by the time you get to selecting the pillars and the foundation you’re going to build your program on, you know all this information. As I mentioned before, if you Google around, the jury is out on how many pillars the foundation of your security program should truly include.

1. CISCO – 5 Pillars
2. Security Intelligence – 5 Pillars
3. OWASP 3 Pillars
4. Bizety 4 Pillars

As you can clearly see, if you spend any time looking at the links above, various security programs use a different number of pillars and each pillar can sometimes mean something different depending on how the program is built and what it means, what it’s trying to protect. The interesting thing is across the industry different organizations have all adopted the pillar metaphor as the foundation to their security program.

From an application perspective if, and only if you’re building an app security program that focuses on applications and your responsibilities and the expectations from you don’t branch out from the applications, focus just on applications. I fully support and agree with the 3 pillars of application security as defined by Gary McGraw in Software Security Building Security in. The three pillars that McGraw lays out for founding a solid security program are as follows:

1. Applied Risk Management
2. Software Security Touch Points
3. Knowledge

I like these pillars for two reasons:

1. Because they’re broad enough to support a very diverse security program yet restrictive in and of themselves such that they’re not overwhelming. There is a lot of freedom in applied risk management, but that freedom is restricted by the second pillar specifying software security.
2. These pillars specify something very critical to me, the state that you believe in applied risk management. 100% of that software security is nothing but applied risk management. They answer the question of how to engage in the security program software security touch points. Lastly, the pillar explains how or what you’re going to need to do to achieve a successful program knowledge

Knowledge Pillar

I’ve seen a lot of security programs be a collection of steps to achieve a desired out come, or a collection of reactive steps/tasks, the program starts here and ends there. Sometimes that’s needed, I’ll discuss that when I come to security program maturity in a future post. However the problem is that, if that’s the mindset of the program, the program in itself never has a chance to mature and get past and stop the bleeding phase.
At first pass, you might think that’s okay my program reacts to issues, and I don’t need it to mature. The truth is that you do, when your program can mature past a reactive state and into a sustainable or pragmatic state, when you do have to react to the damage, amount of time, and amount of work is a lot less, if you can significantly reduce those elements in a pragmatic software program, you can also significantly reduce the cost. Knowledge plays a critical role in helping an organization mature in their security program, as developers and middle level managers change their collective mindsets on the way they approach things, output artifacts be it: code, documentation, web pages, passwords, become more secure, stronger and require less work to fix when issues are pointed out, and actually reduce the number of issues that are discovered from a security perspective.

I’ve also seen security programs where a collection of tools was run and that was our program. Don’t get me wrong, I love security tools and I find them incredibly useful. However, a tool is only as good as the person using it and there’s a reason we still say someone is as dumb as a hammer. A hammer is useful but not very intelligent.
Once, I spent 12 hrs debugging and trying to understand why a static code analyzer was causing new warnings in an area of code that hadn’t been touched in years, turns out a reference was causing this tool to think a code change had happened and mark it for scanning again which introduced a whole set of new warnings which delayed a release. This is an example of where relying on the tools isn’t enough and a policy which states all tools must do this, without allowing an option for knowledge and intelligent thought is a flawed approach to a security program.

Conversely I am a big fan of HP’s Fortify static code analysis tool, however it’s not perfect either, HP fortify might point you at an issue but someone still needed to have the security knowledge to understand the issue and be able to consider investigating it further.

Software Security Touch Points Pillar

This is an excellent pillar because inside of this pillar, it allows for a definition of how the security program interacts with software development teams. This pillar also builds on the knowledge pillar, therefore there is a cross compatibility, those executing items defined in this pillar need the appropriate knowledge to execute the tasks and understand what they truly mean. However, this is the pillar that engages the teams, it can either be the pillar that defines a collective set of activities you want others in the security program to help development teams execute on, or it can be the tasks and how you interface with development teams. Lastly, it can be how development teams engage you under the program, however it should be clear I much prefer the proactive engagement of security teams engaging development teams under this pillar.

This pillar plays a role in defining how big your security program is. The more tasks under this pillar, the bigger the program and the more knowledge folks will need to be successful in the program. Yet, it very clearly restricts the activities and allows the program to say no to taking on work because it clearly defines software.

Applied Risk Management Pillar

This is my favorite pillar of all the pillars because even though it’s “applied” risk management which I truly believe that’s exactly what application security is all about at its fundamental core. This pillar allows for philosophical deviation as well, this pillar really defines what type of security we are going to implement and how it is going to be achieved. The field is wide open, however I would strongly suggest a serious consideration of the National Institute of Standards and Technology for a definitive guide on applied risk management as it relates to cyber security.

This can also define what assets are going to be covered in the security program by figuring out what is going to have applied risk management applied to it and what is not.

Conclusion

These pillars could have been split into 5 or 6 perhaps even 7 to include anymore I think reduces the scope of your security program. It’s always easy to reduce the scope and narrow from a broad base it’s much harder to go from a narrow base to a much broader and remain structurally sound. These pillars provide enough of a foundation to frame a security program but allow you to remain enough creative and intelligent thought that things can still make sense.

The thing to keep in mind is unless you’re at a start up, with no code written, and no products, you’re going to have to find a way to bring existing code and potentially applications under your security program. That last sentence may not sound like a difficult task, however your security program cannot interfere too significantly with existing apps or development mechanisms all at once so chances are it’s going to be a staged and slow implementation having a broad base with some broadly defined pillars allows you to fit things under the program into pillars without too much of a headache and into an existing mold that can be refined over time.