Protect What You Own

Protect What You Own – What CIOs will realize in 2009

For the past several years, security organizations within IT have sprung up at a rate faster than the decline in my portfolio’s value. These organizations have carved a niche within IT that many have claimed needed to be created due to segregation of duties and the fact that IT was not securing the infrastructure. Now with financial pressures, CIOs are looking for any way possible to reduce their costs without impacting the corporate security posture. What many fail to see is that the solution stands directly in front of them and they should not fear driving this to fruition.

Protecting what you own is not a new concept in this world but it seems that IT has never seen this as a core competency or component of their responsibilities. Everyone talks about ‘baking in’ security but the only real way to do this is to protect what you own.

Security organizations have their operations centers, their own incident response plans and programs, their own administrators, engineers, architects, managers, directors and chiefs. In 2009, the question should be: Why?

If I manage the team of system administrators who provide administration and build work over my servers of various types, then I should start having my system administrators building the operating systems to NSA and/or NIST guidelines. I should have my system administrators manage any and all agents on these devices including HIDS, HIPS, AV agents and the like. They should be configured by my administrators and managed by them. My administrators should also manage the central software for each of these agents since the impact is on what I own. It is my responsibility and I am fully accountable for the health of these devices. I own the availability of the devices and for all intents and purposes, I also own the integrity and confidentiality of any data or software that sit on these devices. I need to teach my system administrators that security is a core component of what they do. Just like installing a print driver, installing an agent must be mine and mine alone. When scans are run against these devices, I should have my staff run them to self-test and validate the operating system settings are as they should be and that patches are up-to-date. This is my responsibility in protecting what I own.

If I manage the team of network administrators, I am responsible for the availability, resiliency, and viability of the network and everything that connects to it. I need to ensure that anything that traverses my network is secure and does not cause undo problems. I should be installing, configuring and managing any inline and passive devices that detect or prevent malicious or potentially inadvertent activities on this network. This includes NIDS, Firewalls, content filters, data loss prevention tools and the like. My staff needs to be fully trained in all these tools, fully understand the impact to bandwidth and capacity requirements and validate the need and viability of what they claim to do. I need to protect what flows across the corporate network and must depend upon the trained eyes of my staff to examine this closely. I should be managing network access control onto the network that I am accountable for. I should not abdicate this responsibility nor shirk it giving it to someone who has added the word security in front of administrator and created a separate silo that is costing my firm thousands of dollars more each year providing a service that I am closest to and understand best. This is my responsibility in protecting what I own.

The security operations center (SOC) is a separate group that was created since many pendants and security specialists over the years claimed that having the security eye was needed and that network operations staff couldn’t see what the security eye could see. If I own the servers and network then I certainly must own the monitoring and incident management of these devices and then some. My staff, having built the servers, routers, switches and now firewalls, intrusion prevention systems, content filters, anti-virus, anti-spam and the like will be closest to the actual traffic and fully understand the impact of an intrusion or incident to the devices I own and data I protect than someone other than my team. Why would I think otherwise? The SOC created a separate incident response program different from the ITIL-based incident response we have had for years. How did I allow this to happen? Man, we sure did spend a great deal of money in the name of security. The security information event management (SIEM) solution for the first two years was nothing more than a log aggregator and the logs collected where bloated since my staff didn’t properly configure the logs for only what is truly necessary. Correlation is just now starting to occur since my staff is doing it. I relied on the security engineers to try and figure out what to correlate across all these devices while the real expertise and knowledge rested with my system and network administrators.

It is time to get the incident response programs aligned to one program with situational nuances based upon scenarios. I don’t need two programs and separate software platforms. The impact of the incident is still the same and I surely don’t need to staff a separate organization to do this. This is my responsibility for protecting what I own.

I am responsible for a team of architects but the security architects are in another group. This creates a need for at least two architects for every project that don’t necessarily have aligning standards. The standards that security brings to the table should be fully aligned with if not ingrained in our architectural standards. Considerations for features and functionality must be considered with security in mind but my staff can do this with little training (they may be able to do it now). The security architects and my architects don’t even sit near each other and as a matter of fact, most of the security architects came from my group a few years back anyway. I bet there could be some significant cost savings here if we looked at a single, integrated group. In the end, once the architecture is blessed, it is my staff who has to build it, operate and maintain it. This should be aligned into a single functioning unit. This is my responsibility for protecting what I own.

As for investigations, this is surely a highly specialized group but based upon the metrics over the past few years, I think it would be much more cost effective if we sourced this to a partner company and called in their services as we need them versus paying for full time staff who do not have full time work.  Of course this is dependent upon the size and type of organization you are in and the amount and frequency of discovered issues combined with the company’s desire to go after such issues.

Software development is no different as this organization needs to include security throughout all efforts in writing proper code.  Getting security into the SDLC is not longer and option and having QA treat security issues in code as just another defect is critical to the longer term viability of corporate coding practices.

What it really comes down to is a security organization built 5 years ago upon premises that are no longer valid today. We need to use a risk-based approach to our security and move out of the see, detect and arrest mode to a prevent and remediate mode based upon what is truly of value to the company as defined through information-based meetings to determine risk appetite. In addition, it is time that IT starts taking responsibility for the security of what it installs, configures, manages and maintains instead of creating a separate organization that inherently creates a schism within IT and an air of distrust. With organizations currently built around IT and Security, even though Security may be within IT, you have two organizations competing for precious dollars. When you have IT protecting what they own, the budget is truly consolidated and the choices are different.

What Role Does Risk Play?

One organization that should be separate is that of IT and Information Risk. The days of the CISO are numbered as IT shops begin to realize that they are both accountable and responsible for the security of what they provide. The need for a CISO goes away and morphs into the role of the Chief Information Risk Officer reporting to either a Chief Risk Officer or Chief Compliance Officer outside of IT. Security truly becomes embedded in this model and the costs are reduced through consolidation of efforts. Risk acts as oversight to IT and Information Risk while providing an interface to privacy, compliance, internal audit and overall enterprise risk management. 

Once IT shops and companies begin to realize the value of such a structure, they will rush to it as quickly as possible, to a truly sustainable model and one of maturity.

Will 2009 be the year that corporations begin this move? Yes, the forces of economic requirements ensure that the CIO will raise his/her head long enough to understand the need to move to this model. Proper planning and analysis must occur and the process may take several months to a couple of years, but the move is inevitable. Why wait? Protect what you own!