I recently read a post on a forum frequented by systems administrators titled “I’m scared”.
The text of the post contained something like “they all have local admin access. All of them.”
A few days ago I had a conversation with a colleague about what a small company actually needs in terms of information security. I am used to working in places like international banks and big pharmaceutical enterprises – companies that require a lot of data confidentiality and integrity, and which work under significant regulatory pressure. But what about your typical SME or startup?
It occurred to me that there are three basic categories in the security space that such companies need:
1. “Security management” – this is comprised of setting security policy, understanding what “what” and “why”, performing audits, and generally keeping track of things.
2. “Dedicated security” – the slightly more advanced elements of securing a firm. This includes firewalls, VPN concentrators, intrusion detection systems, threat management, incident response, etc.
3. “Security operations” – the bread and butter stuff. Authentication, data encryption, etc. A good example of this would be login passwords, or Windows group policy.
Category #1 is a control function that oversees the company’s security, from policy and architecture to reviewing implementation and results. Although it’s sensible to have someone dedicated in charge of this, most SMEs will not be able to afford the kind of full-time expert they would need to do it right (which raises the question of whether such a person or function really needs to be full-time in a small firm?)
Category #2 – An SME or other small organization will not, beyond certain very strict limits (e.g. putting black box appliances on its network) have the know-how, time, or money to deal with high-end security technology. Companies hosting their email with an external provider already do this, as do those with managed networks, cloud hosting, etc.
Category #3 consists of tasks and capabilities which really should be integrated in any firm’s day to day IT work. It’s part of what a system administrators must cover as part of his daily responsibilities.
And therein lies the problem for many small companies. Because category #1 is often missing, policy, enforcement, and review is usually weak. People become accustomed to doing stuff by themselves, leading to lack of control, and ability to deal with stuff when it goes wrong.
Let’s say you’re the poor systems admin whose post I read. You start work at a firm with a few dozen employees, a couple of servers, not much in the way of IT budget and a product that, while it relies on IT working, isn’t yet profitable enough to hire a full-blown professional IT organization. Let’s also assume that the first guys to start the company did everything themselves (hooray for startups) and that this idea of “if you want it done right, do it yourself” still permeates your informal culture.
What do you do?
The short answer: risk management 101.
Part of your job as the IT guy is to make sure (a) you’ve identified what’s missing, (b) you’ve suggested ways to fix it, and (c) you’ve made the Powers That Be aware of this and the potential consequences in a way that they understand. If you’re lucky, (c) will lead to a bunch of budget and a mandate, resulting in (d), actually making things better. After all, that’s what you do, right?
This is nothing more than a simplified description of what a proper risk management organization does – make sure there’s sensible rules, make sure everyone’s following the rules, and if someone’s not following the rules, show the people with the money why this is bad and how they can fix it.
Step 1 Policy and Rules. Figure out whether there are adequate security policies in place. These don’t have to be overly complex. Use best practices you find online, shamelessly plagiarize from others, but keep it simple and to the point. Is someone in charge of these? Are they aware of this? Who is allowed to access what? What are the consequences for not following the policy, and is HR/management/aware of these and do they support it? Make sure it’s short, sweet, understandable, and sensible (i.e. don’t make up stupid, complicated rules for no reason other than the security policy seems too short.) Give reasons for what you write down.
Basically this should help your organization define its “risk appetite”. This is a fancy term for what it’s willing to accept and how much it’s willing to spend money on. The key is to make management understand exactly how much risk they face so they can make an educated and informed decision.
Step 2 Document and Classify. Create a mechanism for classifying your assets. Again, not overly difficult. You can use the standard CIA (Confidentiality, Integrity, Availability) way of looking at information, services, applications, and infrastructure. Measure it from 1-3, 1-5, low to high, whatever. Just make it realistic and consistent, come up with a sensible methodology used to rate and sign off on this, and make sure everyone knows about it.
Step 3 Audit. Compare what is to what should be. Who has access to what? Is this stuff being reviewed regularly? By whom? What happens with there results? Who checks logs and who reports anomalies to whom? If you see something wrong, document (1) what’s bad, (2) how bad it is, and (3) why it’s bad.
Does stuff violate your policy, best practice, or just common sense? How? What are the consequences of not doing anything about it? Is it not even possible to find this stuff out (Donald Rumsfeld’s “unknown unknowns”)? Or does your security policy just plain suck? All of these are risks and should be clearly and succinctly documented. The risk severity is nothing more than some function of an asset’s value (Step 2), the likelihood of something happening to it, and the severity of the consequences if something does happen to it.
This can be an educated guess. In fact, most risk management is as much subjective art as science. Just make sure you use consistent logic, rely on policies and standards as much as possible, and be prepared to back up your reasoning.
Step 4 Recommend Solutions. Recommend what needs to be done to fix this. How much will it cost, how much time will it take, and what will the consequences be? I.e. Bob from accounting may have to wait a day for someone to commit changes to his database rather than being able to do it directly himself, but as a result, you’ll have a properly backed up and redundant centralized system rather than a crappy seven-year-old Access installation on a PC in the corner of the office.
Step 5 Obtain Sign-Off. The best policy or audit is useless if it’s not made adequately clear to someone who has the authority to make a decision about it. This is the part where you have to explain clearly, simply, and understandably what you came up with in the above steps – why stuff is broken, why it’s bad, and should be done to fix it. Do you understand this, boss? Can you repeat it back to me in your own words? Great. Now can you please sign it and confirm that you get it? Wonderful. And if not, escalate up the food chain, and create a paper trail that shows you’ve done everything you can to make those ultimately accountable thoroughly aware of all of the above. Because once you have done this, it’s time for
Step 6 Sleep Comfortably. Your ass is covered. You can’t save the world, but you’ve done your best. If your boss wants to stick his head in the sand and refuses to let you help, you’ve now got proof that you really, really tried.
Sometimes you can’t win, and it’s usually very difficult to make people care who don’t want to care – congratulations, this is now no longer your problem.