I apologize for my radio silence last week; I had to run out of town, and lots of things just got dropped. And it was Mobile World Congress Week, so there was some news of note. More on that this week.
But last week I had to attend a couple of meetings in Washington regarding security, which is (or, at least, should be) always a concern with any networking project, let alone wireless. I’ve always suggested that any discussion and definition of an appropriate security policy should be at the core of any security, and thus networking (again, wired or wireless) solution, but I don’t think I’ve ever posted my suggestions on what an effective security policy should contain in this space. So, here we go.
A security policy is just that, a definition of how the enterprise should treat information that needs to be made available only to authorized individuals. I prefer policies that specify performance and not implementation, so there’s no need here to worry about specific product or service details. Instead, focus on the following:
– What needs to be secured – This declares what information is to be defined as sensitive. At Farpoint Group, for example, we define any information belonging to a client, whether covered by a non-disclosure agreement or not, to be sensitive. We also define such elements as the names and contact information of clients, the nature of the specific projects we do, and our own internal operational working information (like financial data) to be confidential as well. You might want to have several levels in your definition here, and if you are specific you thus allow information creators and managers to automatically classify sensitive information without an elaborate review.
– Operational requirements – This is the set of procedures surrounding the storage and communication of sensitive information. We require, for example, that all sensitive information be encrypted both while in storage, and while traversing any network, including our internal network, via a VPN. We require the use of two-factor authentication, although this can be problematic on handhelds – so we restrict the storage of sensitive information on most handhelds by simply prohibiting it. Seem harsh? Try explaining to clients how a lost handset might have compromised the security of their information (something I’ve never had to do, BTW), and you’ll get the religion quickly. You might also want to include requirements for firewalls, virus and spyware countermeasures, IDS/IPS, and similar items here. Again, there’s no need here to define what specific hardware, software, or vendors are involved in the security solution, although you may want to specify such details as requirements for logging, reporting, and any standards compliance, etc.
– Who should have access to sensitive information, and under what circumstances – As one who has held government security clearances (and there any many levels of these), I was always impressed that a security clearance simply qualified an individual to access certain data, but didn’t necessarily allow it. Access is based on need to know, not certification alone. Thus, it’s best to restrict access to sensitive information just to those with a need to know in a given case, and to immediately revoke access if necessary – along with a gentle reminder that sensitive information should be treated as sensitive forever, or until the appropriate authority revokes the sensitivity.
– What to do if sensitive information is compromised, or if compromise is suspected – This is very important. A set of pre-defined procedures must be in place in the event action is required, because time is almost always of the essence when a breach is identified. Access credentials, for example, might need to be changed quickly, attorneys notified (no kidding), and (gulp) clients or customers informed. Yes, I think it’s best to come clean up front. Don’t hide from reality and make the problem worse in the process. No IT security implementation is perfect; learn from mistakes and acknowledge failure when it occurs.
And, of course, it’s best to stay on top of the latest developments in both threats and security tools, and keep your security policy up to date as circumstances change. All of this can be a full-time-job that may IT managers are loath to fund, but it’s like any other insurance policy – a waste of money if you never need it, but worth many times its face value if you ever do. And while I hope you never don’t [sic], the world we live in demands constant, careful vigilance when it comes to protecting information – the most valuable element in any business today.
