If you work in information security you should probably understand the following 5 concepts. Of course there are more than 5 but I lost the use of my right hand in a “Guitar Hero” incident and can only count to 5…presented in no particular order.
5. Shift from a threat focused approach to a risk management focus: FUD spreading is dead. As much fun as it is to scare your peers with stories of AV bypassing rootkits, spawned by cave-dwelling jihadist bent on total destruction through the systematic infection of mobile phones, toasters, and digital picture frames, the reality is FUD isn’t working to free the budget dollars like it used to. Learn to quantify risk, understand the implications to the business and ensure that accepted risk can be mitigated and contained once it becomes a reality.
4. Understand the business: Security professionals tend to look externally at threats as opposed to internally at assets and their function. Assets are more than the sum of their vulnerabilities and the threats against them, they exist to provide a function to the business. This function is variable, as is the importance of the assets themselves. The machine used by Bob in HR - the one he spends his lunch hour surfing between Eva Longoria fansites, ESPN, and this blog - has far less impact on the business than the web application front-end for the customer portal and the systems that support it. Understand the business, critical functions that sustain and enable the business, and how to support the business unit owners themselves - which means you may have to actually talk to someone who isn’t wearing a”hackers do it %6e%61%6b%65%64″ t-shirt, can’t tell the time in binary format, and has no idea who Robert Morris is.
3. For the executives, the board and the bottom line, the A in CIA is more important than the C and I: Yes, I know information centricity, and data security, and an orgy of disclosure with billions of supposed dollars of loss, has led us to believe that confidentiality and integrity of data is the most important thing to the business, but it is availability. Did you know that TJ Maxx (TJX) and Choicepoint (CPS) stock are both at their 5-year high of $33.36/share and $48.14/share respectively and climbing?
2. How much the company funds security efforts is directly proportional to your ability/inability to provide adequate security metrics and proven ROI: You don’t know what metrics to provide and no way to provide them, (here) you have no idea if your security spend has been effective, or if your security program is efficient. No wonder the CIO doesn’t take you seriously. Security has no ROI you say, no way to validate that what you spend is justified - and yet, you stand slack-jawed and shocked when the CFO says no to a budget request for $.5 - 1million to implement the latest NAC/DLP/White-listing/lose weight now ask me how, hyped technology. The reality is that the business is motivated to increase profitability, it’s part of that whole free-market, capitalist society thing. With an impending recession, and the inevitable budget constraints that will follow, you need to recognize that security funding is in jeopardy. Before you leap headlong into an exercise in economic gymnastics and begin a quest to find ROI models that don’t exist, look for opportunities to implement better security controls while addressing the bottom line. As a start I laid out some projects that will make the CFO smile and have some impact on security as well (here)
1. And finally, realize that you probably won’t have the same job in 2012: So all you firewall jockeys and IDS/IPS admins who spent a career learning the ins and outs of ingress/egress traffic flows may want to take a college course on nursing, a field which will explode as all of the baby boomers inch their way towards the golden years.
To follow the thread that you are presenting, security should be designed into, and the ROI justified for an application, service or project based on its ability to positively impact the availability of the application or service. That makes sense. The security incident is an incident not because identities were stolen, but rather because application availability was affected when the application had to be taken off line to clean it up.
So we would justify spending on load balancers with embedded application layer firewalls by showing that the backend servers can be patched less often because the risk to them is mitigated by the application firewall (that also happens to load balance), or that if the databases have proper user account auditing and alerting, the probability of a service affecting application outage is lower, or that if the server operating systems are stripped down, hardened and audited, they’ll need fewer patch cycles or less system admin maintenance.
If this is the case, then we need to look for ways of achieving a rational security model without adding on technology to the ‘outside’ of a service or application, because that would need to be funded & ROI’d separately, and instead ‘build it in’ to the service or application, using operation costs and/or availability as the justification.
Hey Michael,
ROI is a tricky one, I do not believe it is an argument that can be made easily, or at all, with most security technologies. There are some cases where it can, such as security configuration management, where it can be argued that a limited set of environmental variables will reduce support costs, increase turn around time for patches and applications, eliminate configuration drift which can reduce the number of FTE’s required to administer the environment. this becomes easier when you are talking about the benefits of a security technology in terms of availability thoough. This would be an argument for the use of Anti Spam technologies, or DDoS prevention in the cloud or network edge, etc…
Ideally we would want to have security designed into and act as part of an overall initiative, such as support for mobile users or the introduction of SOA or web services - ideally. Today, however, we are faced with having to bolt security on top of other IT initiatives, this is unlikely to change in the near term but we should be working towards it. One method is to implement and enable security as part of the SDLC. An inexpensive first step is to define a standard for log output that can be consumed by the security teams when the application is in production. At the very least, and before you go through an exercise in training internal developers on threat modeling and secure code review (which isn’t easy), and struggle with budget to have these services provided by a 3rd party, you can leverage the auditing capabilities of the application logs to identify policy violations in authentication, usage, and data flow/access.
Amrit, Is there a way to email you info out of the comment section? I’d like to share something with you you might find interesting but I don’t want to be seen as trying to be promotional on your site.