Assurance and the Iceberg Principle

Historically, one of the challenges working in security assurance internally is trying to get involved early enough in the project life-cycle to do some good. The ultimate goal is to be engaged from the outset of a project, provide sound security guidance, inject requirements as necessary, and generally ensure that the project is off to a good start. From an engineering perspective, this is the way all projects should operate -- kind of that principle of "measure twice cut once" (that I learned the hard way once...). You want to get the design as right as possible so that you won't have to make expensive changes after development has gotten far down the line.

Unfortunately, it rarely works this way. In fact, we in security assurance are often looked at with a somewhat annoyed tilt. Project teams know there's a good chance we'll find a problem, levy requirements not previously considered, or simply object to the project in general ("no, you cannot simply post search strings with unique IDs on the web for anybody to download"). In turn, we try to be as flexible and accommodating as possible for projects, with a mind toward easing their pain as much as possible.

In order to address this problem, we've tried to integrate checkpoints into existing development life-cycles, but it's been less than successful. Part of the problem is that projects follow the dev process loosely. Especially with the advent of agile development and the ever-shortening time allowed for development, corners are simply being cut. This, however, often results in sloppily coded applications that lack, for example, very basic input validation. Simple changes that could solve probably 75-90% of common web vulnerabilities today.

So, if integrating into the formal development process doesn't work, what will? In answer to this question, I've been exploring the possibility of moving to the dev organization as a dedicated security resource. I've been discussing this prospect with numerous managers and architects in the group, getting their feedback on such a move. In general, the feedback has been highly positive (both of the idea and at the prospective of my joining their team). But there are a couple persistent questions.

First, there's the question of the appropriateness of having a security person in a dev department instead of in the security department. This question actually has a couple nuances to it. One nuance has to do with missions. The dev group is there to build projects. The security group is there to do security stuff. If you suddenly put a security person in the dev group, are you inappropriately mixing missions? Another nuance has to do with trying to keep the security resource in sync with the actual security department. As the security infrastructure (including policies, practices, etc.) evolve, it would be important to keep up-to-date with those changes to ensure that the guidance provided is still correct and proper.

The second question deals with the effectiveness of an internal (to the dev group) resource in pushing a security message. Some have wondered if moving to an internal role might actually result in a less effective ability to get the security message across. Others have suggested that being internal will allow for getting much deeper into projects (below the waterline) and thus be able to identify issues earlier and address them more proactively. In the end, it's hard to know which result will turn out, though I could certainly take steps to ensure that there was an adequate mandate and level of management support to drive into projects.

As I continue to speak with leaders throughout the dev organization, I think I'll be formulating a plan along the following lines, around the concept of a "security evangelist and liaison" for the department. Qualities of this proposal may include:
   * Strong mandate from (senior) management to address security.
   * Possible matrix relationship back to my current team to ensure staying in sync.
   * Serve as liaison with the security department on key issues such as: compliance (a broad concept); notification and handling of discovered issues (such as in the role of security point of contact); participation in various projects to help get security requirements inserted at the very beginning and to make sure they're kept in the design, with an overall goal of reducing the time required to complete a formal security review; assist other teams with security-related projects/work, such as rate-limiting or integrating security testing into QA.
   * Get out and educate developers. Show them how security can be done sensibly. Help them understand threats and risks. Impress upon them the significance of the risk environment and help them better appreciate the costs involved with getting security wrong.
   * Represent security in the innovation brain trust. I have a very strong desire to be creative, to solve problems. It's something I don't get to do very often. I miss that, dearly.
   * Look for ways to help continue building the positive company reputation. We're doing good things, we're inching closer to the cutting edge. Maybe it's time we do that from a security standpoint, too.

So, we'll see what happens in the coming weeks. A lot of time and thought and discussion will need to go into this idea. There are difficult questions to be answered, which thus far have not been answered satisfactorily. It's unclear if there will be an adequate answer. What is clear is that a) there is a strong need and desire to have a ready resource in the trenches with the dev teams, and b) my current role will not be able to meet that type of need for the foreseeable future. Time will tell if something will work out...