Thursday, January 2, 2014

Information Security 101 for Business Managers

My plan is for this topic to be a running series. I have enough key ideas in mind to provide at least a few posts. The intended audience for these first few will be business managers whose primary focus is not information security, as well as IT Managers  looking for tips to engage with the business and improve how your efforts are targeted.

There are critical areas in your enterprise where business managers can have a bigger impact on information security then the IT team. I'm talking about you, the Manager in Ops or Accounting; even Marketing. Don't tell me Marketing doesn't handle security-sensitive data. I've found your data when I'm doing penetration testing: full copies of customer databases and marketing strategies. And this illustrates my point perfectly; too often management and employees don't think about the sensitivity of their data, haven't thought about how a compromise of data or applications could hurt the business, what level of security is protecting that important data or even where the data is located. This series of posts will attempt to help you solve these issues, protect your business from failure, protect your customers and make yourself look smart.

Principle #1: Know where your stuff is - You have to know where your critical data is stored. You don't need to have the same level of detail on this that IT has, "oh, we've mapped your volume to such and such virtual drive on storage array X." No, you just need some label that will enable you to discuss things meaningfully with IT; something like, "S: drive in the Customer-Service\AppData folder". Don't just tell me, "everything is on our S: drive." Because that contains 10,000 folders, most of which have little business criticality. We don't want to manage it all to the same extent, because it's a waste of expensive IT labor. Whenever an organization tells me that they apply strong protection to all their data, I know right away that they have no idea what they're talking about and I'm likely to find weak controls in place. If you know you have data in a database, list out what server it's on. Maybe the server manages multiple databases, so be specific. Which database is it in? Maybe you can get down to listing specific data tables within the database, but that's difficult and not required at this point.

Note that I said, "You have to know where your critical data is stored." This means that part of your assignment will be to identify what data is critical to your business processes. I'm assuming here that you can define what processes are critical to your business. It sounds easier than it may be in practice. One can definitely be way too granular in listing those out or not granular enough. One hint, you probably have two to six business processes in your department, not 15 (YMMV). If you get stuck on this one, reach out to me and we'll get you some help.  What we're doing is classifying your data.  There are probably templates you can find for policies or procedures on this.  I'll try to cover more in a later post,  but at a basic level, some labels to consider might be "confidential", "sensitive" and "general".  Some organizations get pretty specific with this part of the exercise; others stop at these three categories.  Look to see if your organization already has a data classification policy or procedure.

Another useful way to approach this is to look at your critical software applications. You may as well, I'm going to ask you to list them out anyway. Line of business applications, it goes without saying, are automatically on the list.  Usually we're not concerned with things like Word or Acrobat, but maybe they could be critical to you. Normally we're concerned with applications that store or transform data or communicate that data to clients and business partners. Spreadsheets are a good candidate; anything that accesses or stores stuff in a database or connects to some other system through a network. Internet Explorer would not count, but a business portal web site that you access with the web browser might. We really need to know all such applications that process, store or transmit critical information. Even if it doesn't seem like a critical application, it's important to list it out at this point. You should be able to see where this becomes useful as we delve more into risk assessment in later posts.

One question that might come up is, what do we define as critical?  That's an easy one.  Which kinds of data come to mind when we talk about:
  • Unauthorized disclosure to people who shouldn't see it;
  • Bad things would happen if the data got corrupted or modified without authorization; or
  • We have to have that data or application or web site available to be able to perform business functions or provide services.

We call these business impacts and they all relate to some kind of cost.  Those costs might be in terms of dollars that you can quantify, but it might be less tangible things like loss of reputation or market advantage.

By now you should be asking why we're getting into all these details; after all, don't we normally leave all this technical stuff to the IT guys, the security team or maybe risk management? Unfortunately, most of the time those guys don't really know much detail about everything that you do, how your business processes really function or which bits of data are important.  Sure, they know in a general way, but if they're going to provide assurance for your business processes they need to know in more detail and you have to have it clear in your head in order to be able to communicate it.  Also, and this is huge, you have to tell IT and Security how they should be protecting your applications and data and you can't really do that in a meaningful way if you don't know where it all is or haven't even classified it.  On their own, they would either lock it down so tightly you can't work or, more likely, leave things far too open because they don't know your workflow, your application screens, what might create conflicts of interest, etc, etc.

Next, you need to map out where all these applications live; you'll need to know the names and IP addresses of the servers that they run on.  This is about as deep into technical detail as we're going to get for now, so don't worry that I'm going to tell you to master a bunch of techno-babble.  You don't need to know what an IP address is or what it's used for.  It's just some piece of information to help you track the systems that your data and applications rely on.  This will become more important in later posts as I getting into discussing things like how to turn this information into a risk assessment that just might save your business and your career.  For now, just collect the server names and IP addresses and put it in a chart with your application names and critical data categories.

This can all be captured in a simple spreadsheet.  To summarize, that spreadsheet should have a column for Application Name, Data Classification Label, Host Name (host means "server" in most cases, but allows for other possibilities too), Host IP Address, Storage Location (folder or database name, e.g. "db: sales").  I've gone a little further with this and developed a System Characterization Worksheet for use in past risk assessment consulting engagements.  You can grab a copy from the Downloads page (see tabs at the top).  I created it for a previous employeer, Info@Risk (, who was kind enough to allow me to publish it under the Creative Commons.  I'll give some further instruction for its use in an upcoming post.  In general, its purpose is to document everything relevant for the risks inherent with a particular system or class of systems and the security measures applied for mitigation.  Business process owners, department managers, can begin using it to capture the information discussed in this post and have IT and Security staff complete the parts that fall under their expertise.

So, whether you are a business manager concerned about whether or not IT is giving you adequate support and security or you are the IT Manager hoping to increase engagement with the business folks, hopefully, these topics will be able to get you started on some conversations.

This was all I had in mind to cover for this post.  In upcoming posts I will be expanding on the ideas covered here and providing more tools to make this more useful.

Constructive comments or questions are welcome.  Good luck to you.