You don’t need a Firewall Security Policy
A member of a discussion list I subscribe asked for a Firewall Policy template.
A usual, I was alarmed enough by this to want to comment and drag it back to the discussion on "assets".
I don't think you should have a "Firewall Security policy".
This is why.
A great book on firewalls once described the firewall as
The network's response to poor host security
You can occasionally see articles on host-centric security drifting by ...
A firewall is a "network PERIMETER protection device".
Do you have a well defined perimeter to which you can apply enforcement policies, or is your 'perimeter' like so many businesses these days, a vague and nebulous concept that is weakly defined? One thing that is "in" these days is "De-perimiterization". See "The Jericho Forum".
The firewall model is inherently one of a 'hard outer shell and soft vulnerable centre'. As I said, its based on the idea of poor host security. Good host security will mean that the hosts don't have any un-necessary open ports. Scan you network. If there are no open ports why do you need a firewall?
Oh, right: port 80. And all the hundreds of services behind it.
In effect those are your 'open ports'. Yes, there are firewalls that claim to do 'deep packet inspection'. Check what they actually do.
There are other uses for a firewall? Well some people use it as a NAT device. Some people use it to control outbound connections - "data leakage". What they are really saying is that they haven't built their information architecture in a robust and secure manner. Back to the 'poor host security'. Perhaps you should be doing this sort of thing in your switch or router with ACLs. Partition your network.
So why did I start by saying "assets"?
Some people think that the assets are the hardware.
Focusing on the hardware as opposed to the services, the information and the processes leads you to think in terms of things like 'firewalls' rather than in abstracts like "perimeters" and "access controls".
By addressing a "Firewall policy" you are focusing on equipment rather than fundamentals.
A Security Policy needs to be abstract not specific
- Image via Wikipedia
There's much I don't like about many of the published security policies an the ones I see in use at many sites I visit and audit. But lets pick on ones that deal with passwords.
Firstly, the concept of passwords are limiting.
Are you going to add a "pass-card policy" and a "iris scan policy" and a "fingerprint policy" ?
Of course not. its all "Authentication".
And it doesn't matter where or how or even WHAT you are accessing - policy applies. So the policy has to be general.
The workshops I've run on policy writing open with an explanation of what makes good and bad policy and use this point as an illustration. Good policy is general and isn't going to need to be revised as business
needs or technology - and hence risk and how its addressed - change.
Access to corporate Information System resources
will be restricted to authorized users in accordance
with their roles. Users will uniquely identify
themselves and will be accountable for the actions
carried out under this identification.
Simple language, very general.
You could say it even applies to the to the parking lot at the data centre.
It doesn't address passwords or swipe cards or fingerprints directly for a simple reason.
THEY ARE NOT POLICY ISSUES.
Le me say that again.
Specific controls and specific control technology are not policy issues.
They are standards.
Refer to them. Refer to NIST, refer to the Microsoft documents.
They are not policy.
The _general_ example I gave above is POLICY.
Can you see the difference?
Now read that paragraph again.
Does it say anything about HOW you access corporate IS resources?
No.
So it doesn't matter if you do it at the computer at your desk in the office; from your laptop when working at home over the VPN; from the airport using your smartphone over the Internet. It doesn't matter if the 'resource' is a parking lot, the email server or in 'The Cloud' somewhere.
You don't need separate policies for all of them.
I picked on 'password policy' because its easy to illustrate how a specific like this is wrong-minded and can easily be invalidated by a shift in technology. But the principle applies to the whole of the proposed document.
Why does this matter?
A minimalist approach has much to recommend it.
Quite apart from making the document shorter an hence easier to communicate, it eliminates redundancy and with it the opportunity for sections that talk about what is essentially the same thing but end up
being contradictory.
The example I gave avoids there being questions like
Does remote access use passwords or certificates?
because its NOT a policy issue. A 'remote access policy' might or might not talk about passwords, about SSH, kerberos or X.509 depending on the the bias of a technical writer. In which case its about standards, not policy, and its about access controls, no policy.
Implementation details - controls - must not be embedded in policy.
There a lot more potential for conflict in the document structure as its laid out at the moment.
Why do I talk about it?
Lets leave a policy document aside or a moment and thing of our jobs as Information Security specialists. part of our roles is thinking about what can go wrong, the weaknesses in the configuration and management of the Information systems, management, communication and storage. We think about threats and vulnerabilities.
Now apply that same approach to the document. this one you are calling a "policy manual". Don't take a bottom-up approach, such as arguing over the length of a password or how often it should be changed. That isn't policy. At best its a standard and a highly context sensitive one at that!
Identify what is in common and make it a policy.
I gave the example above of access control.
It doesn't matter whether its access to the workstation, the server, that CRM database, the "pipe" out to the Internet, or the Citrix array inbound over the 'Net from home or an Internet caf�.
It all access to corporate IS resources. It should have one and only one policy. It should not be spread over a number of policies with ifs and buts and different technologies and phases of the moon.
Remember: you have to write policy that can be followed and can be enforced. If users )or sysadmins for that matter) have to remember lots of different circumstances and special conditions then they are less
likely to conform. "Oh, I forgot"; "Oh, I was confused"; "Oh, I didn't think it applied here"; "Oh, I didn't think it applied to me".
That's a start.
Yes, I've picked on "access", but I could equally well have picked on "virus" or "email" or "mobile".
Encyclopedia of IT terms
CMP ChannelWeb have an on-line encyclopaedia of IT terms. This is a useful addition to my toolbar for composition, along with a more conventional dictionary.
The definition of 'information security' seems limited to access control, which is very disappointing. The definition for 'computer security' is more comprehensive. Never the less, to a security professional both these definitions are lacking.
What screams out to me, and this is very obviously my bias, is the lack of any mention of INTEGRITY in these definitions. As I keep pointing out, if you don't have integrity, any other efforts at security, be it information security, or "Gates, Guards, Guns and Dogs" physical security, be it backup and disaster recovery, be it access control, be it 1024-bit SSL, are all going to be pointless.
Its not until we follow a few links at the Encyclopaedia do we come to a mention of Donn Parker's six fundamental and orthogonal attributes of security is there mention of 'integrity'. Even so, that definition has only a like to 'data integrity'. There is a separate definition for 'message integrity'. While these specific items are important, they are details. What is lacking is a general definition of "Integrity". Once again, Fred Cohen's seminal 1997 article on the importance of Integrity comes to mind.
No, a much better reference is Rob Slade's "Dictionary of Information Security", which, of necessity, encompasses many IT terms.
