December 29, 2003

The Eight Rules of Security

Recently I have found myself with the opportunity to continue my ambassadorial role as it comes to information security, and provide some teaching on the basics of security as it relates to business. As I sit here and reflect on just what should be covered in a span of 15 minutes to give the most in depth understanding, I realize that its not such a simple task. Traditionally, people look at the infosec field as something to do about firewalls and antivirus. They treat technology as THE solution, instead of simply the enabler. And it's this fallacy that weakens any security implementation. Security is a process, not a product... and should be treated as such. Through the security lifecycle, policy and procedure needs to take precedence over implementation. It's a bigger part of the circle for a reason.

Anyways, as I think about it more I realize that there are eight components of any good security decision. This isn't new, and has been covered off in writings from people like Kevin Day years ago. And it still applies today. What it comes down to is eight simple rules (commandments so to speak) of information security.

  1. Rule of Least Privilege: Only give enough access to a subject as required to do their job. My favorite quote is "The best security model is the one that lets you do anything" <pause> "that you are supposed to do". A proper policy of least privilege will allow a subject to completely do their tasks without incident. It is only when they go AGAINST their policy do they come up to barriers. It's a subtle but important distinction. If you make the safeguards to stringent or complex, people will try to circumvent it so they can get their job done. Yet if you apply it correctly, they will rarely know about it unless they try to do something they are not supposed to do anyways.
  2. Rule of Change Management: When you make a new change you expose your business to new risk. Any time a change is to occur you must consider all possible security implications. You MUST have a clear and concise change management process that you adhere to. To remain secure you must be aware of changes going on within your environment, and what impact those changes have on you.
  3. Rule of Trust: You must understand the implications of extending trust to anyone or anything within an organization. The rule of least privilege should prevail. Although you may trust your system administrator today, what happens when he holds a grudge towards you tomorrow? Can he bring your organization down to its knees? (Consider reading the exploits of the BOFH for funny examples of just how many admins feel/think. Although the BOFH is fictional, I can speak from experience when I say many of these tactics HAVE been tried in production environments by bored admins) Although Alice may be your best employee, will she be next year? You never know. Almost 80% of all breaches happen WITHIN the network. The internal threat is a significant one, and one you must address with the rule of trust.
  4. Rule of the Weakest Link: The old analogy still stands; you are only as strong as your weakest link. Think about it in for a second. If you spend $25,000 on that new wiz-bang security device, but allow anyone within your organization to directly access your server, how effective is it? Let me give you a more practical example. If you spend $10,000 on a new solid oak front door for your home, $5,000 for a solid metal back door, and $500 on window lock hinges, your entire home security will be worth $500, even though you shelled out over $15,000 to increase your protection. Burglars know this... and will breach through the window. The same principle should be applied when detecting the weakest link in your information security practices.
  5. Rule of Separation: To effectively secure something, you must mitigate the risks associated with it by removing the threats around it. Isolating critical business resources and services to their own machines, followed by strengthening its offerings with the rule of least privilege, will significantly reduce the attack surface of the object you are trying to secure. I see this a lot in the field. People run their entire organization on a single server, exposing the corporation to greater risk than needed. The more subjects that need to access a given resource, the higher the chance is that it will be exposed to greater risk. Separating services to different hosts, and only providing access as required significantly reduces these risks, and strengthens the overall posture of the services.
  6. Rule of the Three-Fold Process: Security is NOT just about technology implementation. Administrators love to install new fancy wiz bang things, but typically don't follow through the entire security management lifecycle. You must include implementation, monitoring AND maintenance to effectively safeguard your resources. You must understand what is being monitored and logged, know when something is wrong and know how to respond to it. You need to keep up to date with what is going on and what your overall security posture is at all times. If you don't, what good was implementing the resource's safeguards in the first place?
  7. Rule of Preventative Action: To effectively defend against the digital divide, you need to proactively assess the security in your environment. You need to keep aware of new security risks that are in the field; Keep current with security tracking mailing lists, RSS feeds etc. Regularly test your defences using vulnerability assessment tools before an attacker does. Maintain a strong three-fold process and keep your systems up to date with the latest security patches.
  8. Rule of Immediate and Proper Response: Long before you are ever breached, you should have an Incidence Response plan put in place. It has been seen in the past, that when an organization responds poorly to an intrusion, they typically do more harm than the attacker did. A rational, well though out response plan can make all the difference. You need to react quickly, document everything and above all STAY CALM. Ensure you have a very clear and widely known chain of command so that the issue can be reported quickly to the right people and get a rapid response. Be discrete (yelling "the sky is falling" is never productive) and follow your plan.

With these eight rules, you will be significantly more secure. Technology will fail. Accept it. With proper policies and procedures in place though, you significantly reduce the impact that it may have on your organization. You will find that riddled through each of the above rules, a common theme exists.... if you only followed one rule, let it be The Rule of Least Privilege. Using least privilege significantly reduces the damage that may be caused when exposed to risk. It contains suspect behaviour to the smallest set of actions and activities, and maintains the confidentiality, integrity and availability of the rest of the environment. And in the end... thats what we want to accomplish.

Posted by SilverStr at December 29, 2003 10:59 AM | TrackBack

Very well-stated and well-written discussion of implementing security. In general though, all of these "rules for security" you hear bandied about sound like the rule for success in catching fish: throw the line where the fish are biting. Trying to implement all of these rules effectively requires a thorough underlying knowledge of the systems involved - which all too often is missing, especially by the managers making such decisions. It is this system understanding of what is always going on that is of most value for ensuring security; too often security rules are imposed without such knowledge under the mistaken belief that they alone are sufficient.

Posted by: Marc at January 13, 2004 08:29 AM

Technical systems are enablers. Processes are enablers as well. People are enablers!

People, processes and systems: in security, all of those are enablers for managing the goal of managing information risk.

We can simplify the statement of the article to the basics: no measure can be more important than the other purely based on ´company resource category´.

All possible technical, procedural and organisational measures ought to be compared together and in an ´objective´ way. The difficulty of this comparison are the strong linkages between the three categories, each of which are often managed by different groups and specialisms in an organisation. Additionally, to be really effective, the measures have to be aligned with what plays at the tactical and strategic political levels.

I don´t think managers have to have technical knowledge. And I don´t think that system engineers have to implement processes. However I do think that everyone involved has to understand that his/her specialism is only a part of the whole and he/she should always try to work in a multidisciplinary way. But isn´t that the challenge of every modern organisation?

Posted by: Daniel Holt at January 19, 2004 04:34 AM

Cool gsm pictures!

Posted by: Twix at February 14, 2004 07:10 PM