Design a Network Security Policy
Most home users can close their eyes and blithely pass over this article. That's not
to say it doesn't apply, just that not many home users want to get heavy and official with
their family, and this article covers the dread subject of Security Policies
What is a security policy?
A security policy is a (normally written) statement of what your systems' users are and
are not allowed to do. It also usually covers some aspects of the sanctions that will be taken
for breaches of the policy. (Now you see why not many home network owners implement a security policy!)
A thorough security policy states the obvious, as well as the obscure:
• If you don't want your staff using work computers to surf the net for private
purposes, say so. Say also what will happen if they get caught doing it. And tell them why
(misuse of business resources, wasting time, traffic costs, impact on other business processes,
danger of virus⁄trojan infections... the list is (almost) endless).
• If you don't allow users to take their laptops home, then tell them.
• One often-missed threat is users taking company laptops home quite legally
and then plugging them into unsecured home networks. Make sure that they understand that
the company security policy applies ALL THE TIME, even when they're at home or on holiday in the Seychelles.
Make sure that the policy is consistent and clearly-written. Consistency is especially
important in its applicability. If the policy doesn't apply to the boss's son or to the IT
director, make it plain in the policy and explain why. Users often use the excuse "Well, he
did it, so why shouldn't I?"
Of course, if the policy is too big, no-one will read it, so use all the advertiser's
tricks to push the point home: login notices, browser front-ends that you have to click 'read
and understood' to continue, training and Q&A sessions, notice board announcements, regular
monitoring and well-publicised sanctions, from verbal and written warnings, up to and including
dismissal for very serious or repeated breaches.
And, once again, make sure EVERYONE knows about it, what it says and who it applies to.
An important issue often overlooked is that the senior staff should be even more careful to
apply it than the junior secretaries. After all, a Financial Director's laptop is more likely
to contain potentially company-destroying information than a salesman's PDA!
Why bother to have a security policy?
Your security policy is a bit like an insurance policy. No insurance policy ever stopped
an accident or prevented a disaster directly, but such documents:
• Make users aware of what they can and can't do and still stay within the
rules - they ignore the policy at their peril!
• Tell users that you are aware of what they do and what action you will take if the break the rules
• Give you ammunition if any action becomes necessary
• Gives your IT designer and support staff a baseline to implement your security architecture against.
• And, possibly most important, prevent any transgressor saying "I didn't know..." or "You never told me."
Creating a Security Policy is always a two-way process - quite often the user⁄designer⁄IT
support will come to you and say "But what about...?"
Remember: No security policy is ever really finished. Goalposts move, new facilities,
services and threats develop. Your IT team should review your security policy every quarter,
and the IT management team or the Board should review it annually.
Visit our computing and networking advice site
Home and small business networking notes.
This is a completely free resource site created by Kerry Anders to provide a comprehensive service
to owners of home and SME networks.
More Network Security Articles:
• Network Security Model - Defining an Enterprise Security Strategy
• How to Secure Your Small Business Network
• The Role of Security Penetration Testers
• Difference Between Network Firewall and Web Application Firewall
• What is Network AAA (Authentication, Authorization, and Accounting)?
• Domain Name System (DNS) Vulnerabilities
• How SSL (Secure Sockets Layer) Works
• Digital Signatures and Certificates
• The Use of HoneyPots and HoneyNets to Trick Hackers
• Remote Access Authentication Protocols