BSides Dallas/Fort Worth (BSidesDFW) is this coming Saturday, November 2, 2013 and we are lucky to have yet a sneak peak at another of the amazing sessions, this one on security requirements and how they often come up short.
Presenter Brian Mork (@Hermit_Hacker) will be taking attendees through a tour of some of the security requirements he’s seen over the years and demonstrate where they failed.
“There are classics, creative fails, and epic fails, all in equal numbers. Names and details have been changed to protect the (somewhat) innocent,” Mork said of the talk.
Mork is an Information Security Business Partner with Alliance Data Systems, Inc. and sits on the board of advisors for the Dallas/Fort Worth Information Security Leadership Forum. He got his start as a hacker back in the early 90s when he wanted to play games on systems that didn’t technically meet the required installation standards, and he refused to take that as the final answer.
About a year ago Mork made a change of career and switched to the financial services vertical, where he acts as an independent security consultant to the ADS Retail Services line of business. He now spends his free time hacking away at Linux hardening scripts, paste scrapers, distributed password crackers, and finding ways to improve the efficiency of the hacking team he co-founded (@Cryptolingus).
Mork holds a Bachelor of Science degree in Information Technology, is a Red Hat Certified System Administrator, Red Hat Certified System Engineer, and holds the CompTIA Security+ certification. He is a current nominee for the Information Security Executive North America, Project category for his work on leveraging the user experience of cloud services to improve the security posture of data storage.
Mork says that security requirements are critical to the design, execution, and implementation of projects, and if they aren’t included in the initial requirements documentation they will be a bolt-on at best or excluded at worst.
“Some organizations have started to recognize this and proactively require security requirements, but often have non-security personnel write them or non-technical people modify them,” Mork said. “An entire talk could be devoted to writing clear requirements, but this session will focus on some of the ones that I’ve seen make it through review processes that might appear to have value, but really just muddy the waters or are entirely too vague.”
Mork says the real challenge is providing developers and implementers a set of requirements that will capture the elements that actually improve upon the security posture of a product or process while not specifying the manner by which that improvement takes place.
“I wanted to talk about this topic because it’s really the first injection point into the development or deployment process that most security organizations can affect, and it can have a significant impact on the design considerations and logic used in choosing paths forward,” Mork said.
“However, when we write requirements like the system shall encrypt data, we can end up meeting a requirement by doing things like ROT13. Sure, it’s technically an encryption, but is that really the intent the requirement?”
Security should in all ways be an enabler of the business or environment, and the vast majority of what security professionals do is not defending against the latest zero day released by a Romanian hacker to target IE as the media would have some believe.
“We find ourselves on a daily basis figuring out how to fix what are essentially systemic issues,” Mork said. “Well-written security requirements are arguably the best tool we have in information security to ensure that the products and processes we use have taken a rational, considered approach to security.”
Security requirements are the one solid method we have of influencing the final posture of a process or project, yet they are often or generically ignored in favor of statements like the system shall be compliant with ISO 27002.
“These types of things look good on paper, but are horrible from the perspective of the developer or implementer,” said Mork. “There are literally hundreds of potential derived requirements from a blanket statement like that, and who will be the one doing the implementing? Odds are it won’t be someone with a security background. Even glossing over the number or requirements we come to more problems, because standards often have conflicting guidance based on how a system has been assessed or classified.”
Mork says his hope that this presentation will open eyes to the opportunities we too often squander when it comes to providing security inputs, and recognize how we can best take advantage of these events to have a meaningful impact on products and processes.
“By walking through requirements I’ve seen over the years that move from the flat-out comical to the insidiously malformed, I hope to educate the audience on critically analyzing the requirements they work with and provide concrete examples of how to improve upon some of the requirements that they are (likely) already using,” Mork explained.
He says the biggest challenge with actually understanding security requirements and their role in development processes is coming to terms with the scope.
“In a previous position I had a project manager who blithely stated that we would comply with a particular assessment level in a government-standard, and put that into the contractual language to make the sale,” he said. “Only afterwards did they come to my team, at which point we enumerated the over 200 requirements they had just committed to meeting.”
When they actually saw the scope defined like that, Mork said they promptly began trying to find ways to kill requirements because they realized that they couldn’t deliver the product they had promised within the funding they had won.
“Situations like this have two diametrically opposed results: they make developers and implementers aware of what creating a truly compliant product or process entails while simultaneously introducing some risk aversion on the part of sales people / bidders for security requirements in future projects,” Mork pointed out.
He says the resulting responses follow the Kubler-Ross grief model surprisingly well in that at first there is denial that a product or project has in any way failed to meet security objectives, which shortly turns to anger at the security requirements author over “adding” to the workload.
By midway through the development phase the bargaining begins, with requests to loosen or ignore certain requirements. As the full impact of the requirements really sets in a sense of depression with regards to successful completion may occur, followed by acceptance of what needs to be done.
“Fortunately, in my experience this works as a sort of security requirement inoculation: Future projects using the same personnel are much more likely to request and author detailed security requirements during the project scoping and definition phases,” Mork said.
Security requirements won’t be going away any time in the foreseeable future, and as the complexity of the systems we rely upon and services we consume continue to increase they will likewise increase in importance.
“The marketplace has shown time and again that while a poorly designed product (from a security perspective) may gain initial traction and uptake, with that popularity will come increased scrutiny and – in many cases – exploitation,” Mork said.
“Baking security in from the very beginning of the process is absolutely essential to reduce and qualify/quantify the risks associated with the projects we oversee.”
Cross Posted from Tripwire's State of Security
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.
Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.