January 06, 2005
The "Higher Security Mindset" - Seven Best Practices to Keep you Safe
Recently I received a couple of emails in regards to some of my posts where I refer to the fact we must have a "higher level" of thinking when it comes to information security. The question in these emails asks just what higher level means... and what it consists of.
I wish I could take credit for this type of thinking, but it really was taught to me by Kevin Day. However, I don't mind passing it on to you to further that knowledge to others. Most of this is ripped from his book "Inside the Security Mind", and I highly recommend you check out the book if you don't already own it.
When looking at infosec as a whole, we got to stop worrying about the next wiz bang security tool and start thinking about security best practices that when followed, will help to keep an organization safe. Even though the security landscape is constantly changing, these practices (when applied) will adapt to the highly dynamic nature of information warfare and allow you to repel your adversaries without much incident. And that is what makes a higher security mindset.
So lets talk about seven best practices, that when applied, will do more to protect you than running to buy the next wiz bang security tool uninformed.
Think in terms of Zones
Zoning is the process in which you define and isolate different subjects and objects based on their unique security requirements. For those uninitiated to the terms, a "subject" is a person, place or thing gaining access. An "object" is the person, place or think the subject is gaining access to. I use the terms generically since when zoning you really could be applying it to anything. A file, a server, or even the physical access to your safe. You have probably seen the concept of zoning in Internet Explorer where Microsoft breaks zones down into the Internet, Local Intranet, Trusted Sites and Restricted Sites. This is just one example of how you can break something into zones. Of course the concept of zoning can be applied anywhere, as long as each zone treats security in a different manner.
Although I have seen most people think of zones in a network-centric manner, it doesn't have to be. It could apply to applications, physical areas and even employee interactions with others as a defense against social engineering tactics.
Anyways, a zone is a grouping of resources that have a similar security profile. In other words, it has similar risks, trust levels, exposures and/or security needs. For example, an Internet facing web server will have a different trust and exposure level than an intranet web site. As such, the two should be in different zones. Though you can have umpteen different zones, typically the most common scenarios involve three zones:
These three zones can apply to almost anything, from network based services, application programming and even physical security layouts.
The trick is separating zones in such a way so that we can maintain higher levels of security by protecting resources from zones of lesser security controls. The separation mechanism between zones could be as simple as a firewall, a piece of managed code or a locked door. The goal is to have some degree of control over what happens between the zones. And have logical communication medians to allow for zones to communicate safely where appropriate.
Theoretically it would be nice to live in isolation and never care about other zones. But in reality, at times some zones will need to be able to talk to others. If we didn't allow that, you wouldn't be allowed on the untrusted zone of the Internet from your trusted zone of your internal LAN. It would have to be severed. The trick is to understand the risks of exposure when communicating between zones, ensuring that some sort of filtering safeguard is working in between to determine what is, and more importantly what is NOT, allowed to communicate through the filter. As an example, there is a much higher level of risk in allowing a direct inbound connection from an untrusted zone to a trusted zone. This is why we have firewalls on our perimeters. (You DO have a firewall between the Internet and your computers don't you????) And the risks are significantly reduced if we place an untrusted inbound connection into a semi-trusted DMZ.
See how this all fits together? Zones give us the ability to reduce risk by applying technical safeguards in a logical manner through grouped resources. How we communicate between a trusted and semi-trusted zone would be different than an untrusted to trusted zone. And we can make better security decisions by understanding that.
I have been using a six-step process that Kevin showed me to apply the zoning concept into the decision-making process for infosec. The following procedures can help in that process:
Since the dawn of time, chokepoints have been a key part of security practices in warfare. A chokepoint is a tight area of control wherein all inbound and outbound access is forced to traverse. Kings of medieval times understood that if you could funnel the enemy through tight doorways it makes it much easier to pour down fiery oils on them. Likewise, its much easier to keep a thief out of your network when the network only has one gateway leading in and out. In the infosec space, chokepoints also grant us the advantages of:
Chokepoints are a critical component of a higher security mind. They greatly reduce the infinite number of possible attacks that can take place, and thus are some of the best tools to use in information security.
One thing to consider when using chokepoints though. They also become single points of failure. As such, it is important to increase the availability measures taken in relation to the number of access points consolidated. As an example, if everyone has to go through a single point to access the Internet, it might make a lot of sense to ensure there is a level of redundancy at the chokepoint.
Applying chokepoints is pretty easy. Here are some simple steps when contemplating chokepoints:
I think Bruce Schneier said it best when he stated that "security is a process, not a product." When looking at security architecture, it is important to recognize that no single device is without flaws. Every significant application, server, router and firewall on the market today harbors some vulnerabilities. Additionally, most of these same resources have a good chance of being misconfigured, unmonitored or improperly maintained. On their own, each object will eventually become a weak link that would allow an attacker to get in. As such, layered defenses are crucial to repel intruders and ensure that any one weakness on its own will not let an attacker in (or out for that matter).
Layered security is a hot topic and I don't have to really go into great detail. But here are a few things you can do to apply layered security in your organization:
Understand Relational Security
Information security involves numerous chains and relationships. Any given object will almost always have a series of relationships with other networks, applications, events etc which will prove to be of great significance to our security considerations. The security of any object is dependant on the security of its related objects, and if we fail to see these relationships, we will be unable to properly address security. This is called relational security.
A server, for example, may be considered safe because it is not connected to the Internet. It is, however, accessible by the administrator's home computer through a dial-up session. The admin's system itself is connected to the Internet through a broadband connection. Thus, by following this chain of relationships, the server is actually connected to the Internet. Following such chains can point out where systems and networks that are considered to be safe are, in reality, vulnerable. And this is exactly how hackers typically gain access to systems. They go in through less secure back doors to gain access to more trusted systems.
Vulnerability inheritance is probably the most vital and yet most neglected security relationship. The level of vulnerability within any object should be considered in relation to the vulnerability of its related objects. A file share between a secure system and a vulnerable system greatly diminishes the security of the secure system. If the secure system is accessible in any way from the vulnerable system, then, to some degree, it will inherit those vulnerabilities.
This is exactly how modern worms breach sensitive systems. Which is why I think its NUTS to have things like nuclear power plants remotely accessable. When will we ever learn!!!
Understanding Secretless Security
The best security solutions are those that rely as little as possible on secrecy for protection. Relying on secrets for security has several weaknesses. For examples, secrets tend to leak out. If you keep your life savings under your mattress, and yet talk in your sleep... your secret may be easily compromised. Secrets can also be guessed. A thief breaking into your house may just look under your mattress during the burglary. If you magnify this problem by a few thousand end-users and several administrators, then you will probably spend more time securing your secrets than securing your valuables. Let's look at some classic examples where secretless security is commonly applied.
Have you ever heard the phrase "don't put all your eggs in one basket"? Never have all your investments in one industry; never rely on a single person to do a critical process; and never, never, assign all security responsibilities to one employee, one system, or one process. And, if you are a security professional, make sure you are never the one with all the responsibilities and power. (Even if you WANT to be a BOFH... don’t)
Separating responsibilities does not stop with personnel, however. This concept applies just as strongly to placing all our faith in one security application, or one security device. If Server X is the only thing protecting our entire company, performing filtering, content management, intrusion detection and authentication, and running VPN and logging, we have a security issue. No system is perfect, and no security device is unbreakable. (No matter how many vendors claim their's is... even when offering rewards to hack it) At a minimum we should have something monitoring and protecting the security of our main security devices.
Here are some standard management practices you can take to divide responsibility within your organization:
If you read my blog at all, you know I typically talk about this when talking about designing secure software. It is more important to test the code execution paths when something fails, than when it succeeds. This same thinking should be applied to the higher security mindset.
Everything is subject to failure, no matter how robust or expensive it is. Such failures often lead to lost productivity and potential security issues. As such, potential failure scenarios should be considered before any new implementation. When programming an application, failures should be made to lock down security. When a network architecture is designed, failures should not result in bypassing security as is commonly done. It should fail "CLOSED" (to not give any access). If a power outage occurs, services, applications and devices should apply security during the reboot process. Consider failures in all devices and services, walk through the contingency plan, and consider the security implications therein. This is especially essential for major failure plans like disaster recovery policies.
I used to get annoyed with Windows Server 2003 when you rebooted after a power failure. (Our battery backup only lasts an hour right now, and doesn’t signal Windows properly to halt *sigh*) It always prompts you for a dialog to explain WHY the system shutdown unexpectedly. Then I realized what a great opportunity this was. This allowed us to consolidate the logs and make business contingency planning decisions about power based on knowledge collected in the audit logs for the Windows servers. Understanding that on failure it rebooted and then prompted the admin before it would startup allowed us to track what was going on at all times. And this has been very useful information as we make decisions on our new office architecture needs in relation to power.
So now that you are thinking...
If you apply these seven security best practices into your daily infosec life, you will really move to a higher security mindset. Policy decisions will be made with a more informed basis and you will be able to adapt to the dynamic nature of the information security field. Although it may not be perfect, it will go a long way to assist in effectively applying the technical safeguards within your organization. And that is what will make you a better security professional. Not because you know how to configure and use the next wiz bang security product. Because you will know how to apply it in the midst of your security best practices to make it work FOR you more effectively. Posted by SilverStr at January 6, 2005 03:43 PM | TrackBack