How To Secure The Enterprise Network: The Basics.

This series on network security is for enterprise organizations looking to have a more robust policy in place.

While everyone in IT management worries about security, far too many organizations lack even a basic security policy, a document that can provide guidance to IT in the never-ending quest for secure operations. Yes, I really do mean never-ending – absolute security is, and will remain, an abstract, theoretical concept. Hackers are always busy exploring potential vulnerabilities, so our goal needs to be making security so reliable, and so strong, that all but the most hard-core information thieves will give up without getting the goodies they seek.
But any effective information security strategy needs to start with a policy document that includes three key elements: (1) A definition of what information is sensitive and should therefore be secured, (2) Who may have access to this sensitive information and under what circumstances, and (3) What to do in the event of a breach. Let’s look at each of these in a bit more detail.
First, not all information, within most organizations, anyway, needs to be secured. There’s usually little strategic value in the cafeteria menu or a casual-Friday notification. But, keeping in mind that, apart from talented and dedicated staff, vital and proprietary information holds the greatest value within any organization – and once compromised, this data is lost forever. It’s a good idea to define multiple classes of security (“private” and “most private”, for example) with a more restricted audience as the strategic value, so deemed, increases. The Security Policy should define these levels and who is authorized, by job title, to so classify documents within the organization. It goes without saying that sensitive information should be encrypted when in residence (on a server, PC, USB key, cloud storage service, or anywhere else), as well as in transit, via a VPN. Again, specific technologies are not necessarily defined in the Security Policy, and these may regardless change from time to time. The keeper of the Security Policy is normally the individual or group within the organization chartered with ongoing security management, so he/she/they will ultimately be responsible for implementation and enforcement as well. Keep in mind that the Policy will likely require updates over time, along with every other activity related to security.
Defining who can have access – again, via job title – to any given class of sensitive information is the next step. This is the domain of authentication and authorization, and these topics are so important that we’ll cover them in detail in another article. For now, start with usernames and passwords – but we won’t stop there.
And the final element, what to do in the event of a breach, is vital but often overlooked. Breaches in security often occur well in advance of the recognition of such an event, and our goal must of course always be to prevent such in the first place. But if a breach should occur, immediate actions, including changing passwords, freezing access log records, and notifying those affected as defined in law or regulation and/or the Security Policy itself, are required. The Security Policy will also specify who is responsible here as well.
Finally, let me suggest that, while the Federal Government is obviously no paragon of virtue with respect to security [a link to a story on the recent break-in here?], the security model used within the US military provides a good deal of guidance with respect to security policy. The Pentagon defines multiple levels of security (unclassified, confidential, secret, top secret, and etc.), and clears individuals to a particular level, with higher levels requiring a more detail background investigation. And just because someone is cleared to a particularly level doesn’t mean they automatically have access to any given piece of sensitive information – a “need to know” is also required. Secured information is careful tracked with detailed rules as to how it may be communicated and otherwise handled. And more elaborate encryption (often using two or more separate encryption tools) is required as the security level increases.
So – don’t expect perfection in security. But a good Security Policy can go a long way towards making organizational information security as perfect as it can be.

While everyone in IT management worries about security, far too many organizations lack even a basic security policy, a document that can provide guidance to IT in the never-ending quest for secure operations.

Yes, I really do mean never-ending – absolute security is, and will remain, an abstract, theoretical concept. Hackers are always busy exploring potential vulnerabilities, so our goal needs to be making security so reliable, and so strong, that all but the most hard-core information thieves will give up without getting the goodies they seek.

But any effective information security strategy needs to start with a policy document that includes three key elements:

(1) A definition of what information is sensitive and should therefore be secured.

(2) Who may have access to this sensitive information and under what circumstances?

(3) What to do in the event of a breach?

Let’s look at each of these in a bit more detail.

Which data needs to be secure?

First, not all information, within most organizations, anyway, needs to be secured. There’s usually little strategic value in the cafeteria menu or a casual-Friday notification. But, keeping in mind that, apart from talented and dedicated staff, vital and proprietary information holds the greatest value within any organization – and once compromised, this data is lost forever.

It’s a good idea to define multiple classes of security (“private” and “most private”, for example) with a more restricted audience as the strategic value, so deemed, increases. The Security Policy should define these levels and who is authorized, by job title, to so classify documents within the organization.

It goes without saying that sensitive information should be encrypted when in residence (on a server, PC, USB key, cloud storage service, or anywhere else), as well as in transit, via a VPN. Again, specific technologies are not necessarily defined in the Security Policy, and these may regardless change from time to time.

Who owns the Security Policy?

The keeper of the Security Policy is normally the individual or group within the organization chartered with ongoing security management, so he/she/they will ultimately be responsible for implementation and enforcement as well. Keep in mind that the Policy will likely require updates over time, along with every other activity related to security.

Who access what?

Defining who can have access – again, via job title – to any given class of sensitive information is the next step. This is the domain of authentication and authorization, and these topics are so important that we’ll cover them in detail in another article. For now, start with usernames and passwords – but we won’t stop there.

In the event of a breach

And the final element, what to do in the event of a breach, is vital but often overlooked. Breaches in security often occur well in advance of the recognition of such an event, and our goal must of course always be to prevent such an event in the first place. But if a breach should occur, immediate actions, including changing passwords, freezing access log records, and notifying those affected as defined in law or regulation and/or the Security Policy itself, are required.

The Security Policy will also specify who is responsible here as well.

Defining the Security Policy

Finally, let me suggest that, while the Federal Government is obviously no paragon of virtue with respect to security, the security model used within the US military provides a good deal of guidance with respect to security policy.

The Pentagon defines multiple levels of security (unclassified, confidential, secret, top secret, and etc.), and clears individuals to a particular level, with higher levels requiring a more detail background investigation. And just because someone is cleared to a particularly level doesn’t mean they automatically have access to any given piece of sensitive information – a “need to know” is also required. Secured information is carefully tracked with detailed rules as to how it may be communicated and otherwise handled. And more elaborate encryption (often using two or more separate encryption tools) is required as the security level increases.

So – don’t expect perfection in security. But a good Security Policy can go a long way towards making organizational information security as perfect as it can be.

Click here for part 2 of this series where authentication is discussed.

All Posts In This Series:

Reality Check: Your WLAN Is Already Supporting BYOD. Now What’s Your Strategy?
BYOD Doesn’t Have To Be A Challenge

1) How to Secure the Enterprise WLAN: The Basics.

2) Authentication a Key Part of Any WLAN Security Policy

3) Is Security Possible With The Cloud?

mm

Craig J. Mathias is a Principal with Farpoint Group, an advisory firm specializing in wireless networking and mobile IT. Founded in 1991, Farpoint Group works with technology developers, manufacturers, carriers and operators, enterprises, and the financial community. Craig is an internationally-recognized industry and technology analyst, consultant, conference and event speaker, and author. He currently writes columns for Boundless, Connected Futures, CIO.com, and various sites at TechTarget. Craig holds an Sc.B. degree in Computer Science from Brown University, and is a member of the Society of Sigma Xi and the IEEE.

Leave a Reply

Your email address will not be published. Required fields are marked *