One of the worst things about being in a poorly-respected security organization is the fact that you're often handed a ticking bomb without the ability to diffuse.
Not being able to influence the requirements due to either lack of understanding, or a lack of comprehensive threat assessment can be a terrifying experience for an IT professional... Allow me to explain.
Imagine yourself as an IT project manager, given the requirement to build something the business has deemed critical to its operation. Now, even if you think security is an important thing, you're often faced with the same problem I've been faced with in past employment - you cant do it securely.
Understanding the role that requirements play in security is critical to understanding the concept of security itself. You see, security in and of itself is meaningless. A state of 'secure' doesn't matter unless it's applied to an asset, or something of value.
Is the coffee cup on your desk secure? Maybe, but against what? What is the value of the coffee cup, and is there any protective measure for it that makes sense? What are the threats?
Threat modeling software is a delicate art, and often mis-understood enough to cause confusion, poor execution which likely leads to a state of poor security. It seems elementary that the best, and possibly the only, time when IT has a chance to impact security in a positive way is during requirements gathering, yet many security professionals continue to ignore that opportunity.
Instead of working hard at influencing requirements, we work hard at the tail-end of project, adding blinking lights into closets, introducing more technology and cost, and rarely adding any real business value.
The problem with diving into requirements right off is that many IT Security professionals don't have the tools and training to properly address requirements - so there are opportunities to slowly back into this practice. Performing proper threat analysis is one of those methods.
Threat analysis can be performed at various stages of a project - whether it's done at the requirements level or design... or sometimes even during (or even after) development. The brilliance of threat analysis is that the earlier in the development of a project it is done, the bigger the positive impact and less likelihood of higher costs and delays.
Think about it - if you could perform a threat analysis on an application you're building for your business-critical project, wouldn't it make more sense to perform that analysis on the requirements, then again on the design to ensure security sanity is being followed and built into the application?
The problem comes in when you realize you're just not qualified to do a comprehensive threat assessment... or worse yet, you're also the firewall 'guy' and simply don't have time.
These are very real challenges, and they're being met in today's business-heavy IT climate through partnerships, consultants, and self-education. The challenges are executing when you've got the green light to perform the assessment.
It just so happens that if you need assistance with the process of doing a comprehensive threat assessment against a business-critical system or application, we've got some support for that here at HP.
While I won't go into detail on the service offering, you can read up on it yourself at the link below, I will say that if you're not getting that support from us - get it from somewhere.
Comprehensive threat assessments of your applications and systems are a must-have for those critical projects. Understanding requirements, influencing them sanely, and then performing a threat assessment against those business requirements to create a security-safe design plan... that's what makes applications risk-averse...
Links:Following the White Rabbit