Process, not just product, will save your IT department
RTFM is not enough
So, you’ve bought your firewall. You’ve spent thousands on an intrusion prevention system, and you’ve got expensive data leak prevention software. Are you dead sure that your sensitive customer data hasn’t been leaked?
In IT security, capital expenditure on products can help to protect your systems, but it isn’t enough. Thinking about security when designing and executing your everyday IT processes is a key part of guarding your infrastructure. Moreover, it might help to reduce your overall security expenditure.
“CISOs spend a lot of money on firewalls and anti-virus,” says Jeremiah Grossman, chief technology officer at at WhiteHat Security, which carries out penetration testing services on client systems.
Grossman argues that large companies typically invest lots of money on developing software, and desktop and server infrastructure, with less spent on network infrastructure. Conversely, he argues that the CISO targets security dollars on network infrastructure first, investing in expensive firewalls, with less spent on desktop security infrastructures, and even less on things like secure development lifecycle in software. “So he’s out of phase with the business,” Grossman concludes.
This doesn’t mean that you shouldn’t buy a firewall, of course. Nevertheless, focusing purely on throwing tools at the problem rather than thinking more generally about security processes risks making security more reactive, and piecemeal. What does a properly orchestrated set of processes look like?
There are a variety of operational maturity models to choose from, each with their own strengths and weaknesses. ISO 27001 covers enterprise security in the broad sense, and ITIL includes useful points on security within a services framework. These can be effectively integrated with other models to create an operational maturity model for security. For example, it is possible to map ISO 27K and ITIL against the Capability Maturity Model Integration (CMMI), which provides the framework for assessing operational maturity. Using this mapping, you can frame your security processes according to five levels of capability. The Control Objectives for Information Related Technology (COBIT) also provides a framework of governance and control that encompasses security practice.
Systems integration consultancy CIBER uses a seven-layer model as the basis for its operational security maturity programme. It starts with a programme layer that covers funding, strategic planning, and cross-functional oversight. The management layer covers asset risk management, security skills, roles and responsibilities, while the next layer, documentation, involves asset classification, procedures, and policies. Atop these layers sit the others: education, protection, detection, and response.
Documentation is an important part of implementing standard security models across the enterprise, according to CIBER, which talks about an umbrella security framework that allows for traceability for security regulations and external requirements. Documenting your assets is important if you are to fold them into processes that help to protect your corporate infrastructure.
CIBER advises companies to create a roadmap for use as part of its ‘protection’ layer, which will link the technologies that you invest in to your long-term security goals.
What processes should you focus on when defining these long-term security goals? Much will depend on your company’s unique business requirements, but broadly speaking, we can identify some common critical areas. Vulnerability management and intrusion protection are important, as is identity and access management. Here are some key things to keep in mind when designing security processes that will guide your roadmap:
Know your infrastructure A sound asset inventory and configuration management database is a critical piece of the puzzle. Without this, you won’t know what you have, which makes it impossible to manage it properly. This becomes a serious problem if, for example, someone plugs an unauthorised access point into the network,or downloads un-verified applications,or hooks up a USB hard drive for instance . Is it yours, or is it theirs? How would you know, if you did a wireless networking audit?
Automate its management Ensure that critical processes such as patch management are as automated as possible across servers and PCs, operating systems and applications beyond just Microsoft (third party applications are the greatest sources of risk), so that procedures necessary to bolster corporate security happen quickly. Automating other processes such as the scanning of new devices connected to the network will help to ensure that rogue devices don’t pollute your environment. This is one area where process and product intersect, but it is also an area where security budgets can be wisely applied.
Use systems management tools as your eyes and ears Effective governance includes discovery of devices on the network, so that they you can first of all figure out if they’re yours or not. Make sure that your management tools watch your network and systems for you, alerting you to problems that could indicate a security issue. Why, for example, is that newly-attached PC suddenly blasting out traffic to every PC in the local subnet on an unusual port?
Check your logs Mine your logs for useful information, possibly using log analysis software. Drawing intelligence from your logs can help you to identify attempted attacks (and perhaps successful ones).
Positive Feedback Loops It may seem obvious, but above all do remember to learn from your experiences. If you encounter an incident make sure that the relevant holes are plugged, that configurations are tweaked and users educated. You might be able to buy software that will do most things for you, but process – of which positive feedback loops are one – are the things that really keep you secure.
Compliance, is of no use without accountability. Shirking responsibility seems to be more fashionable in this Oprah winfrey culture.
Another one for Steve
To repeat his often used mantra RTFM is dead those that do not get it will be also
Last but not least Technology is a verb not a noun ( repeat for security / firewalls ad infinitum )
How many dumb companies have purchased security systems by name instead of what they could ( or could not do.
Cheered on by the sturm and drang IT apocalypse mob
I wouldn't buy a firewall...
... I'll build my own from FOSS. I got skills, baby.
Snooty snobbery aside, if you have to drown your shop in (E)TLA soup to keep it going, you're doing something wrong. Yes, prefab models and methodologies are all the rage these days, but they're like cookie cutters. Useful if you need lots of cookies cut, not so useful if you're a chef and would be far better served with a nice and sharp knife.
Seens to me most enterprise IT is full of cookie cutter users, or at least so would the confident salesmen have you believe, so lusts the pointy hair and so hire the HR drones. Might be at least some of them would be better served with a chef instead.
Personally, I dislike frameworks with a passion. And that's in this as much as in software. There, and I have little reason to believe this'll be different, they're excuses to set up grand schemes full of scaffolding and allusions to universality and such, then fill it in with "useful" code that does things that make sense within the model, but much of that code often enough sees little use and not terribly much debugging. Possibly the warm buzzy feeling of working within a framework is to make up for the overall poor experience and performance, bang per complexity, and so on. In the process field, I need only say "six sigma" and make basically the same point. Mixing and matching smaller "frameworks" to get the same thing is, well, a different approach, I'll give you that. But that doesn't automatically make the whole thing a good idea.
Don't get me wrong: There's nothing inherently faulty about the idea of modelling and framing what you do. It just isn't automatically a good idea to go out and fetch yourself a couple then throw them in the organisation. Modelling is a tool to help you think.
What's happening here, however, is that a few bunches of people thought up a lot of stuff, possibly as a result of years in the field and so on, and are now selling the resulting thick books, reports, consulting services, and so on, and so forth, and are making a pretty penny out of the resulting cookie cutter selling business. And that's fine, of course, it's a free economy. But ask yourself: Does your business really need more cookie cutters?