Working in a large organization often means many different projects, topics, areas for discussion and different places for security to get impacted. When one of these applications has a poor security model or makes a bad decision and provides a way for an attacker to get in, or a way for an attacker to steal enough information that can be exploited later, this can lead to several security implications for the organization. There is a supply and demand problem right now with security folks within the industry, there is a supply shortage, that’s a problem for another time, however because of this supply shortage having a qualified security person consider your project, it might be hard to do depending on the number of security folks your organization has. Last time I checked, human cloning wasn’t readily available and I am not capable of duplicating myself. How do you ensure scalability of your security resources to have enough engagement in all your projects?
Scalability – People Don’t Scale
People don’t scale, or we scale pretty poorly, however this doesn’t stop projects, work and a million other things in our lives from scaling all around us. There’s a reason why when new projects come around and the capabilities of an organization grow, the organization needs to hire more and more individuals to get the projects done. Sure these projects could all form a back log and wait, wait some more but business probably wouldn’t like that.
When organizations mature and realize the need for a security team, review and security added to their development processes, they tend to hire security engineers, which are separate and apart form InfoSec see: InfoSec is Not Enough. Typically, these security engineers come on board and execute on the Microsoft Security Development Life Cycle or some other development model that builds security into the organizations practices. As I mentioned, there’s a supply problem with talented security individuals in the industry right now. If an organization is lucky to have one or two or three talented security engineers, it’s quite easy for these engineers to quickly become over worked and stressed out, after all there’s only 8 hours to do work in a day and nobody can work all night, etc. What ends up happening is that the security engineers or the security team quickly become a bottle neck, due to the fact the organization cannot supply enough resources, because the industry can’t supply enough resources. What you can fix by hiring more developers, project managers, architects, managers, you simply cannot fix by hiring more security resources if they’re not available. So what ends up happening? Well, senior managers get grumpy, then everybody gets grumpy and processes and policies change so that maybe not every project needs a security review or needs to engage the security team, and only critical or really big projects need to be engaged.
The problem with this engagement model is that it's just transformed an argument from an imperative argument into a subjective argument. Organizations are just beginning to mature enough to realize they have a need for security in their development processes, enabling them to choose the engagement is an experience that needs to come when an organization is mature in its security practices. Bringing in security & a subjective decision on when to engage it simultaneously is a recipe for disaster.
Why Subjective Engagement Fails
Organizations are very mature in their software development practices, but maturity in one practice doesn’t mean maturity in all practices even if those practices meet the software development practice. How can you expect an organization that is just introducing security into their development practices to have enough knowledge and experience to know what security needs to be done and what security doesn’t need to be done? – You can’t.
As a security individual, I wouldn’t dream of coming into a new organization and telling the organization what aspects of its development practices it can keep doing and which it can stop doing. In fact, often times when doing a security code review, I have some questions about the design, coming from a strong development background and continuing to develop code, sometimes I see things that just don’t make a whole lot of sense in the architecture, sometimes the design over complicates the problem or it’s just a bad way of doing something. However, my job and function is to lend security expertise and ensure that whatever is done is secure, I cannot and I should not force a project or code back to the drawing board because I think there is a better way to design and produce the problem if I haven’t been intimately involved since the project inception. – The bottom line is I am simply not mature enough in what I am looking at!
Subjective Engagement will fail because security practices take time and effort, the larger the application the longer they take, hopefully these practices are being engaged as part of the normal development. If they’re not, well that’s a different problem, but the work will take even longer. However if your security resources are overwhelmed, and the organization isn’t mature enough to make a deterministic security approach on its own, then inevitably insecure software will be released. If 4 projects are being released and security is only involved in 2 of them, then 2 projects have a chance at being really secure and 2 don’t. At the end of the day, has the security position of the organization improved? Yes, has it improved as far as it could have? Not a chance.
Another reason the subjective engagement model fails is because the wrong people are making the decisions, project managers want to get projects done pushed out the door and signed off on. They’re not as reckless as that, however I have met some aggressive project managers in my time. I am not going to knock project managers, they have a tough job and I honestly wouldn’t want it, however a project manager is the wrong person from a technical perspective to determine if a project needs to engage security or not.
The end result of subjective engagement as I like to call it is you have to few security team members not being actively involved in important projects because the folks that are making those decisions are not the right people. The project doesn’t even show up on the security team’s radar sometimes which can significantly set the security position back. The other major downside is that the security team is often chasing projects. I’ve got enough work to do than to chase projects and hear tidbits and try and reconcile whether projects are meant for security or not and need to have me engaged.
Trying to chase after projects is often bad and ineffective by the time I’ve learned of a project, and if I have to chase it, it’s too late for me to really do anything about to improve the security posture of the project before it goes to production. Either me or my security colleagues are often left scrambling to attempt to determine how and when to make security changes needed to fix what may have been released.
Scalable Engagement
People don’t scale well, and subjective engagement doesn’t work well, given that security experts are in relatively short supply, this is a difficult problem to be solved, although you shouldn’t fret it’s already been solved for you. When you consider how large organizations solve the scalability problem of development, they hire more people, the security problem can be solved in a similar manner.
An organization doesn’t need a huge security engineering team of highly trained security engineers such that they can assign one to each project, it would be fantastic if they had those resources but I have yet to see an organization like that. A much more sustainable model is what I like to call the security council or the security champions council. This council looks somewhat like this.
The council model takes the approach of building a security council out of your technical folks (PM’s, devs, QA, whomever). The idea with the security council is that these are individuals with what I like to call a bias in security. They are interested in security they might know a bit about security but they don’t want to get too far removed from the code they like what they do, they’re interested in it but they also want to know how to make things better, from a security perspective.
The way the security council works is the council’s first objective is to bring projects to the security council for engagement, this can be a meeting, E-mail, what have you but meetings work best. A meeting is usually chaired or co-chaired by the security engineers. The security council evaluates a project and marks it for engagement, further evaluation, or no engagement. This way all projects get brought to the security engineers and a wider security audience. The reason projects are being brought forward is because these are the exact projects members of the security council are working on. So now, you have an avenue to ask everyone what as many as the development teams are working on.
The security council can help bring about security decisions, designs talks & educate each other within the scope of the security council. It is the responsibility of the security engineers to work with the council, to provide guidance, education mentoring, tech work, designs, if required.
The security council members are responsible for executing on the security development life cycle projects within their teams, but don’t have to get caught up in dealing with InfoSec or Exec’s on security related items. What ends up happening over time is as the security council’s skills within the organization improve, and grow through collective engagement, the education and mentoring of the security engineers, you train up new security engineers but even better then that the security council members can begin to start helping themselves on all matters security. This begins to allow your security engineers to focus on improving the security program, new initiatives and guidance, working with InfoSec to take the development teams in a new direction, and allows the whole development organization to respond much quicker to a security related problem should it arrive. This also has the added affect of lessening the blow to your organization should one of your security engineers decide to leave you’ve got a whole pool of folks that might be quite interested in moving into that role.
The post Scalable Security Engagement Problem appeared first on Security Synergy.
