There is a great lesson that unfolded at one of my customer’s sites during an audit. It is a great story to tell, but more importantly, it lets me illustrate that as Security Professionals, we need to design security to work in a way that makes them natural to the business. I know, shocking isn’t it? But it can be done…
During an audit of a company’s security program the gentleman doing the audit asked for evidence of “…specific Security Testing…” in the development process. The development manager responded, “We do testing, but not any specific Security Testing. We do code reviews by someone who hasn’t written the code but is part of the same team so they understand the objectives and how it might impact other code. We use the material we receive from annual training we have with our development tools vendor on how to write more secure and stable code. We do data input and processing tests to make sure the system doesn’t break. Then we test the functional specifications to make sure we met all the design specifications.”
The auditor’s answer was, “That’s not specific Security Testing.”
I stopped the auditor and asked him to tell me what “specific Security Testing” was. His answer was, “It includes testing of the code, looking for security vulnerabilities, testing with tools that look for security problems, testing for error conditions or code failures that could result in the disclosure of data. The testing you do here is Functional Testing.”
So I asked a question of the Auditor:
“What is the ideal objective that we, as Security Professionals would like to see when we look at application development?”
When I got the same response back about what is specific Security Testing, I responded, “What if a software development program includes Security from design, through functional specification, through development and into testing. Security is built in to every aspect, and it is natural. Is that not a better model?” There was affirmative nodding.
“Then, is it not appropriate then that a company include Security Testing in their existing testing methodologies and refer to it as Testing rather than as specific Security Testing?” At this point there was some silence on both sides. I then prodded the development manager who proceeded to discuss how Security was wrapped diligently in their design and functional specs, and that their input and processing testing included many of the elements of specific Security Testing that the assessor was looking for, but they never called it Security Testing. It was called just Testing.
Let us be honest about something. Not every development team thinks this way. I happen to have a few very brilliant managers at clients who think this way. Hats off to them. But our goal as Security Professionals is to get all of our clients to think this way! Security should not be a standalone activity operated in isolation. Security should be a natural part of what we do every day. To paraphrase many security professionals, if we naturally did the “secure” things we should do in the first place, we wouldn’t need much of the artificial layer of protection and tools we build.
We must drag auditors, assessors, and every other critic away from their “Deformation professionnelle” – their tendency to look at things through the lens of their profession and forgetting about the bigger picture or the real goal. In the case of software development, most auditors think of the world after we decided (unilaterally) that developers can’t do it on their own, so we must put in place controls, tools and other activities to stop their bad code. Instead the goal should be to create an environment where the developers do include security in their processes – at every step.
I don’t argue against the tools that are used in Security Testing. I just argue that keeping these tools and processes out of the developers hands tells them it is okay for them to write bad code. You are implicitly telling them that it is someone else’s job to make sure it is secure. What we as security professionals need to do is hand that responsibility back, give them the tools, give them the training, and assign penalty and blame when they do not take up the bit.
The lesson from this little story? Let me walk you down the garden path:
a) Security should be built in as a natural part of our existing business processes. It becomes a cultural and behavioral change.
b) Security should be everyone’s responsibility, not one group in isolation.
c) We need to play the coaches, not the ringleaders.
Being in the Information Security profession is a lot like being someone’s coach or trainer. Your goal is not to run their business, or to swing the golf club. Your goal is to adjust them so that they improve their performance and results.
