Beware of Pink Driveways
When approaching the challenge of how to leverage a small, and in some cases tiny, Information Security staff to reach all of the teams, management, and projects that might have security risk, I turned to my days as an IT consultant. Adapting a consulting model for stretching Information Security resources works, but be careful to not go too far.
IT Security Gets No Respect
Does the following sound familiar? IT Security has limited staff that is seen as intrusive by the groups it interacts with. It is seen as a bottleneck because of the backlog of work we have. The bottleneck includes being the only group that can use the security scanning tools because of the expensive per-seat licenses of the product. When teams see the results from these scan tools they almost faint at the long list of flaws found but then are frustrated when their research drops out the false positives, causing them to question the accuracy of the tools. Project managers own their schedules but wince because many IT Security departments determine if a product can release or not, not them. And to make things harder, security efforts that integrate into projects are seen as cumbersome and time-consuming (which is the kiss of death for Agile software development). Let's face it, IT Security is often not respected, is avoided, and not wanted. Adopting a consulting model can help.
And Now, The Role of Consultant is Played By. . .
While I was a consultant, several characteristics were the hallmark of what I did. I was there to solve a problem, help a customer meet a goal, provide value, then leave with the potential of return business. Consultants help companies to focus their efforts on goals they probably already know but are having challenges to reach. That's when I stepped in with a plan and having the answers for how to tackle nagging problems, like software quality (now with a security twist). As a consultant you help people see the big picture but know how to work with the realities of what the situation is. You form alliances where you share expertise and leverage lessons learned from customers; you give to get cooperation and project success. I would focus efforts for a situation, determine when to stop, and then not overstay my welcome. If I did my consulting right, one success led to another challenge that I was asked back to help fix. Often, this approach fosters incremental work, raises quality, and enhances security over time.
In IT Security it is about weighing risk, looking for easy and big wins, but always needing to re-evaluate the ongoing risk and countermeasures. Achieving total security in just a day would be nice, but without state, federal or industry regulations that dictate security responses to vulnerabilities, security's role is downplayed or put off for another day. A consulting approach focuses on adding value today and repeatable follow-up over time.
Being a Security Consultant While Not Being a Consultant
While it would be nice to advise projects on IT Security with a consultant mindset, your IT Security job at the company is to make sure bad guys don't break the software and steal data, identity, customer confidence, and company reputation. Many IT Security functions have authority to stop releases, but heralding that potential risk should stop a software release will lose when compared to releasing product with certain revenue.
So, infuse your IT Security efforts with “consultant tactics”:
Volunteer Information and Give Without ReceivingLet's face it; IT Security is in most companies the new kid on the block compared to long-established development practices. Work security into the vocabulary used in development. Security often sees the bigger picture of software architecture and what affects reliability. Use that knowledge to help in design sessions or solving QA issues. Sharing information and advice in one area will get you in the door for when you want to promote security practices as another part of quality.
Make Things Seamless and Part of What Projects Already DoIntegrate security practices, processes, and tools into the development schedule and practices. Be sure to not slow down work or releasesProduct releases may need IT Security sign-off, but promoting "security enforcement" will get resistance. . If something is easy to use or do, people are more likely toembrace it.Focus on being part of the feature planning early in a release where flaws found from the last release can be tagged for fixing early in the development cycle. Critical security flaws should not be let out the door, but shifting from stopping a release for every flaw to continuous improvement early will make a difference.
Have a Plan - Identify How to Integrate Security Into Existing ProcessesIT Security is not in many software teams’ vocabularies, so have a plan. Introduce ways to integrate security methods incrementally and over time. The easier you make it part of the existing quality testing and feature requirements processes the better. Teams will fight "security fixes" late in development, but are completely comfortable with "feature requirements" early that happen to be about security. Provide code chunks for ease of programming, give training that tells how to look for or resolve a flaw. You will be ahead of the game if management sees the incremental plan for security quality instead of just a mandate to "fix X flaws within X days".
Back the Grand Plan With Specific AnswersHaving a plan means having answers. That means educating people on something that was not part of most college educations, is still a fairly new field, and struggles to keep up with changing technologies and exploits. Provide easy-to-use guides and sample code. Host brown bag education sessions and write up bulletins on understanding a security flaw so they don't have to surf the ocean of information (often conflicting or too narrow) on the Web. Do whatever education you can to make security easier to do.
Timing is EverythingDo everything early in the software development lifecycle. Test for flaws and identify their resolution early. There will be less surprise and more time for them. Later in the cycle and developers will be more concerned with whether their release gets out the door as planned than making security concerns a priority. Existing flaws - security debt - tends to accumulate and takes time to reduce. Educating the product teams on security when their focus is coding takes time too. All of it means tacking security early and repeating it the next time. Over time the products will adopt this mindset as well.
Let People Have OwnershipWhether accurate or not, projects expect you to come and then go. Do just that since most security teams cannot place a "security buddy" on every effort from start to finish to maintenance mode. But first set up the overall security processes and knowledge that is repeatable and then work early and hard during the development phase, lessoning the emphasis closer to testing, stabilization, and release. This approach leverages when the projects are most available and receptive to security change while meeting your goal of integrating into their cycles.
Contractors Paint Pink Driveways
While I have been an IT consultant, I have also been part of "supplemental ongoing labor" as an IT contractor. When it comes to Information Security you want to be a consultant and not a contractor. Consultants will show the plan for better IT security while ultimately the effort is done by the projects themselves. If you do most of the assessment, tracking, and managing of the security issues, you follow more of a contractor model.
In a contractor model, the contractor often fulfills what the customer wants done and how they want it. The role of consultants is to provide vision and sometimes break difficult news to their customers so a better solution can be found. When I was an IT contractor, a fellow contractor compared our jobs to painting driveways. If a customer wants a driveway painted “blue” one day and "pink" another, then we will give them the best pink driveway they ever saw! The contractor model results in the security team running the scan tools, working the issues, and taking ownership of the security issues. The consulting model shifts the emphasis to the teams to own the security issues that only they can fix, with you providing direction and guidance to add value.
Its About Partnerships and Alliances
In the end, the consulting model is about teaming. You are not in control but a contributor with a game plan. You tactically apply your resources – tools, processes, and people - so they can be in more places at one time. As a security consultant, you work to raise awareness and be a smaller version of you. You help projects to recognize, own, and fix the security flaws they created. Security is often seen as having less value until a breach happens. Taking the consulting approach adds value, spreads resources, while emphasizing security goals.
~ Kenneth
