IT Security Strategy: Thinking Inside and Outside the Glass Box

 
 
By Scott E. Christiansen  |  Posted 2008-09-02
 
 
 

As the chief security officer at Leo A Daly, a Omaha, Neb.-based architectural and engineering firm, I often describe IT security as a sealed glass box filled with a green liquid. The glass box represents the organization, and the green liquid represents all our different data types.

The box provides excellent transparency into the organization, and the green liquid can easily be seen and contained, but it’s still protected by the structure of the glass box. To me, this is a traditional approach to security: taking what is valuable and allowing it to be seen, but having very stringent controls in place to contain and regulate it.

The next step involves either allowing more of the liquid (data) into the box or controlling the process of extracting it from the box. Again, this process is generally administered via strict controls, which are similar to a series of pumps and pipes.

During these addition and extraction processes, the IT department usually spearheads the control of these pumps, determining who has access to which pump, which direction the liquid is flowing in, and what the flow rates of the pumps are. (See illustration.)

This process may have worked well in the past, but as employees, customers and the business as a whole require a more flexible environment for storing and accessing data, this glass-box approach begins to show its limitations. What happens if your box fills up? How easy is it to expand a sealed glass box? More importantly, what happens if your box is breached and your liquid—valuable corporate data—spills out? How do you know what information was leaked?

Removing the Lid

“Opening” your glass box is the first step toward alleviating the problem of increasing the size of your sealed glass box without spilling your green liquid. If you remove the top of the box, you still have the same transparency as before, but now you also have the flexibility to easily expand your box as your employees, customers and business groups demand. You will need corporate buy-in for this, but most businesspeople will find this flexible IT security strategy attractive, once they learn how it can help them.

The second step involves separating your green liquid (all the different types of data) into different components (a variety of different colored liquids) through data governance. This process involves understanding what you are storing and categorizing your information: AutoCAD drawings, building information modeling, images, proposals, requests for proposals, contracts, price quotes, etc. This enables you to group your data and easily build a taxonomy. (See “Grouping Your Data” at end of article.)

Once you understand what the data is, it’s easy to develop pathways that match the data’s taxonomy. For example, if you have a price quote that should be seen only by your sales team, upper management and a client, you can design an information store for that data, back it up as necessary, and place filters on storage resources or endpoints that scan for keywords or metadata identifying what type of document it is.

This will prevent users from circumventing your approved channels. Subsequently, you can also deploy a system that allows the client to securely log in and obtain that information.

These processes are dependent on a document’s sensitivity. Sending an e-mail message with an attached PDF price quote containing a nondisclosure statement may be all that’s necessary for that document type. But you would undoubtedly have more stringent requirements for documentation on a product you’re delivering to a government agency.

Now that you can easily expand your glass box and are intimately aware of the various colored liquids (data types) inside, it’s time to understand how to get those different liquids in and out of your box. I recommend giving your employees, customers and business groups the tools to pour in their own liquids.

For example, by providing employees, customers and business groups with a blue pitcher to pour in a blue liquid (which could represent contract documents), you are implementing a control for that type of data. However, you are also providing the users of that pitcher with the flexibility to pour in as much or as little as desired. When the blue liquid enters your glass box, you know where it will rest inside the box (the location in a specific server where the data is stored). This process is essentially your access control. (See illustration.)

There is a similar process when extracting your blue liquid (in this case, contract documents) from the glass box. By providing employees, customers and your business groups with a blue spigot that rests at the same layer as your blue liquid, you are allowing them to extract as much or as little data as they require, while understanding that it is only the blue liquid that is pouring from that spigot. No other types of data can be accessed from that spigot. (See illustration.)

Who Is Accessing What?

Through change control and configuration management, you can identify when a particular pitcher (methods of adding data) or spigot (ways of accessing data) is used. You can also identify potential cases of abuse, such as when too much liquid is going out, when a spigot has not been turned off, when someone has damaged a spigot during use, or when an employee or customer doesn’t know how to use a spigot properly.

I use the example of setting a policy for the acceptable use of an e-mail system, particularly determining when file attachments will be blocked. For instance, you could block all outgoing Microsoft Excel e-mail attachments, but you should provide employees with another method of sending those files: a publicly available FTP site, an internal/external Microsoft SharePoint site, a second-party hosted file-exchange system or some type of secure document exchange.

The type of system really doesn’t matter, as long as it is easy for employees and customers to use, and allows them to do their jobs using the pitchers and spigots you provided. But you should implement controls that allow only the actions you wish to permit, along with auditing measures to ensure that the systems are being used appropriately.

The process is the same in the Web 2.0 context, which is requiring organizations to open their glass boxes. Employees may wish to use instant messaging to communicate with outsiders, but IT may be worried about allowing publicly available IM clients inside the organization.

The solution may be implementing an IM technology that allows users outside the company to access it (Microsoft Office Communication Server 2007 has this functionality), or putting in systems that separate and filter out this type of traffic.

I recommend setting a policy that outlines the types of information considered unacceptable for employees to post on the Web, and referring to a standards document that outlines specific technology (such as company-sponsored blogs or wikis) that’s to be used for specific company-related information. By having the proper policies in place, you can lay out a blueprint of how you envision all these processes working.

If you want your security program to continue to be accepted and integrated into the business, you must ensure that you position yourself to be as flexible as the business calls for, while still maintaining the proper measures of control.

Grouping Your Data

Creating a taxonomy is an important part of data governance. The following are some suggested classifications:

Document Type: Is it a project plan, a contract, a specification, an answer to a request for proposal, a price quote, a memo, etc.?

Document Format: .doc, .xls, .mp3, .mov, .pdf, etc.

Owner: If questions arise about a particular document type or its contents, the owner should be able to tell you everything there is to know about it.

Sensitivity: Is the data public, public within a limited scope (specific client information), internal only (confidential business strategy plans), internal within a limited scope (employee salary information or social security numbers), or does it contain other information that’s unique to an individual (such as passwords)?

Access Control: What users and groups should have access to this information?

Critical Level: Is the information business-critical, semi-critical or not at all critical? Could your business survive if the data were lost?

Access Frequency: How often will the people who need this information actually access it?

Retention Length: How long do you want to keep the data? How long do you have to keep it (federal mandates or legal liabilities)? How quickly should you get rid of information such as temporary files, information placed in a file-exchange location or e-mail?


Scott E. Christiansen is the chief security officer at Leo A Daly, an architectural and engineering firm in Omaha, Neb.