Draft: A Step by Step Security Approach for SMBs

Suppose you're a newly appointed CISO in a SMB. Suppose that position is a creation.

I've had to think about it as I'm currently advising a few fellow CISOs. They're in positions where IT security is just one of their responsibilities because the structure is not big enough to afford a full-time CISO. The rest of their time, they act as IT project manager, network administrator or company's archivist!

In this position, you may want to have a look at comprehensive guides/norms/references about IT security. But how to handle an ISO 27002? How to handle an ISO 27001 when it's a newly created job and you can't muscle into decisions? How to spread awareness that you don't want to do everything in those norms, but only the most important ones for a small structure?

I recommend the following steps, in the approximate order I give. (Experienced security people might be surprised that I don't place the policy and the charter at the top...)

First steps: gather documentation, work alone
You're going to write documents that will follow you everyday on your work and that you'll want to have at hand even in the corridors of your workplace. I call them the "Books of..." for this reason.

1. Write the Book of Activities in which you'll list every task that IT people think it's their job to do. You can do that by striding through IT documents, chatting with every IT people and doing a week in the Service Desk (or equivalent)
2. Write the Book of Services in which you'll list every Activity that's sold to the end-users (whether in speech or money). For each of them, list the description of the population of end-users and the arguments used to sell the service. For instance, "the firewall" is an activity but not a service because it's transparent to end-users. "Mailboxes" is both.
3. Write the Book of Legal Constraints in which you'll list the precise references to legal texts and their implications for you. You'll have to do it one day, so better do it from the beginning.
4. Write the Book of Classification in which you'll note what special kind of information deserves what special kind of treatment. For an SMB, I would suggest to only consider legally-constrained classification. For instance, classify medical data or military data, but don't go into making classified categories such as public, private, secret, top-secret, HR-only or anything so detailed.
5. Write the Book of Risk Analysis in which you'll create a grid (basically a sieve or even a checklist of threats that might occur to your information system) to think about risks whenever needed. That will be especially useful at the beginning of any IT project that you want to secure. You'll be more confident because you'll follow a long-time established list and people will trust what you say more because it won't have popped out of thin air.
6. Write the Book of Integration Requirements which you'll append at the end of any RFP, in which you'll list all of the technical conditions the chosen solution will have to fulfill. It will also be helpful if your company does some internal development, you'll just have to distribute it to developers. You can get that list by going to network and system administrators and asking them for what went bad in their past integration experiences. You'll get 90% of it in just 30 minutes of discussion.
7. Write the Book of Physical Security Requirements, which you'll forward to people in charge of electricity, building access control, fire prevention and so on.

Second steps: set up inventories, work with the admins
You're going to make sure you know your assets, you know your perimeter and you're going to make sure that IT people don't get lost into the mess of an IT service. (Tcha-tching!)
For these steps, you'll have to initiate the work but the admins will have to keep up on the long run.

See, that's not just writing docs, that's about having the right information to make the right decision when needed. That's about billing customers with exactitude. That's about enabling statistics on the activities.

1. Make sure you have an Inventory of Users, which may include all employees, contractors, providers and customers. Once you have that, you'll be able to work on identification and authentication. (Please ensure that an authentication project is never started before the identification is correct. Even if this sounds too stoopid to happen.)
2. Find or create the Inventory of Network Equipments.
3. Find or create the Inventory of Endpoint Computers (desktops, laptops, macs, iphones, huge display screens...) You'll usually find one or more partial inventories when you arrive in the company. It is part of the CISO's job to make sure that this inventory is not partial.
4. Find or create the Inventory of Printers (and other multimedia hardware).
5. Find or create the Inventory of Servers.
6. Find or create the Inventory of Server Software.
7. Find or create the Inventory of IT-Managed Endpoint Software.
8. Find or create the Inventory of Providers and related SLAs.
9. Find or create the Inventory of Network Flows and Zones. Internet, VPNs, mailing service, DMZs...
10. Find or create the Inventory of AntiVirus Software and AntiSpam Software (or the Inventory of Not-AntiVirused Flows and Not-AntiSpammed Flows if that's quicker).

When you've made sure the inventories listed above are up-to-date, you can say you've reached your cruising speed. You can start auditing, advising, collecting data to prove an intuition, intervening in a decision process, etc.

Third steps, cruising speed, work with strategy people
Now, you're aware of your perimeter, you have a good overview of the risks, you may even formulate a strategy. You'll want a few more tools to formulate it, have it approved and execute it. Listed below are the main tools of the CISO. They're in no particular order, contrary to above. You may use them at your convenience.

• Metrics. Once you've decided a technical point, measure the degree of conformance to this decision. Once you've set your objectives, display your progression publicly.
• Supervision and logs. Realtime supervision will give teams the power to act before the Service Desk gets a call from users. Logs will help the teams go back on an incident and prevent its re-happening.
• Redundancy and High-Availability. If you've spotted a specifically sensitive point in the information system (like the central user directory, or the billing system), ensure they are redounded and can switch from one to the other within minutes. That alone saves your company days of lost work a year and saves the IT service days of cold sweat.
• Software Update. A big risk is associated with old versions of software (not just vulnerabilities, I mean: bugs, difficulty for the Service Desk to master multiple versions, impossibility to remotely detect the version, longer phases of test for the integration of new software/hardware, etc.) So get a piece of software to detect installed software, versions, and remotely distribute updates.
• User Charter. The users want to be told what to do plus they need to be told what not to do. Additionally, you gain immediate influence and respect of the Charter just by mentioning that someone actually is in charge of IT security. Try to make a new version every year, don't put too much but make sure the basics are never forgotten.
• Information Security Policy. This document affirms, company-wide, the separation of responsibilities in terms of information security and this is the place where you can get the CEO or the Board to sign that you have the autority to do a specific thing. Usually, it's not made for anything technical, it's made to sort internal power struggles or budget affectation. It's boring for the CEO, so don't make more than one new version every two years but make sure you get support on the most difficult human and managerial issues you encounter.
• Risk Management. A risk is a sum of money or time that the company loses because of the happening of a threat. When you know the threats, when you know their probability of happening, you can estimate a risk and treat risks in descending order. That's called risk management (I saved you a book!) A CISO usually gets that by gut feeling, but it's always good to confirm it with analysis and it's better to show that you don't decide on things just by gut feelings. You can see it as a way to help others make decisions about IT security (CIO, CEO, budget planner...)