Last updated on: 1/29/2009 11:05 PM
Created on: 3/21/2014 2:18 PM
When considering implementing security in your IT project there are several aspects that need to be addressed in order to increase success. First and foremost security considerations should be an integrated approach and not treated as a patch that can be added in later. By integrating security practices early on in the process you can strike a balance between technology and policy that can ease the concerns about incidents when they happen. Adhoc fixes are harder to enforce and require additional training for users which in turn increases the chances that the security practices won't be followed.
The success of your security practices can be increased by applying specific considerations into you IT policy. First and foremost, any security policy or practice must support the mission of the organization. This security policy must be an integral element of sound management, which means it has to be easy enough for management to actually use it. Management is after all the example to the rest of the organization. The security policy must make the responsibilities explicit. Finally, security is not a one-time investment. Any implemented security policy must be reassessed periodically.
It is recommended that the security policy check against the goals specified in the organization's mission. This includes having a policy that respects privacy and obeys (or knows) the laws that apply to an organization. One of the main areas of concerns are e-mails, which in some cases are not considered private communications between parties. If the security policy doesn't respect such privacy factors it is doomed to fail. Instead the policy should focus on areas that need security to be addressed. A good example are medical offices that have to obey the regulation specified in the federal HIPPA laws.
It is also important that when generating the security policy to be familiar with the acceptable privacy policies. Each company has different practices. A good policy will consider how formal the company is in terms of communicating and dress code. The more business causal the organization is the less likely a formal security policy will be accepted. When making these considerations be sure to plan ethical operations. Determining the ethical practices and disciplines at the start will make rolling out a security policy more acceptable.
The following lists of managing risk is not really a list but a cycle. Since technologies change, advance, and have additions made to them, this list requires constant review.
- assets - what do I have
- threates - what will attack it
- vulnerabilities - is the asset at risk
- safe guards - can I reduce the risk
- likelihood - will it happen
- consequences - how much do I lose
There are several different assets that need to be considered as part of the policy. The first asset to look at is hardware. With the digital revolution everything of value now rests on physical devices. Having data on one hard drive is not a good practice considering if the hard drive should die. A security policy should consider the back up of information including when and where. A strong security policy will specify what to do when (not if) a piece of hardware is lost due to disaster, theft, or normal mechanical failure.
Protection of software also needs to be considered. Most organizations have records of purchased software such as Microsoft or IBM products. However many larger organizations have in house developers that create custom applications. In addition, users may download smaller programs or macros to help automated tasks. These downloads normally don't have a record of their use with the IT department. Any software that is used in daily tasks of the organization must be protected and the policy needs to cover this situations.
System interfaces is an area that needs to be addressed by the security policy. The interfaces are the ways in to and around the network both internally and externally. In most cases firewalls are configured to handle these access ways. However most firewalls are placed at the point of entry of the Internet the the local area network. This worked and in some places still works, however wireless access points now add additional entry points to the local area network and must be looked at just as closely.
Data & information are the more obvious assets that need to be protected. Most people consider user's files but a strong policy needs to expand to cover client databases and e-mail. With e-mails wide spread use many discussions and business transactions are logged in the inbox.
A security policy also has to cover the asset that is the people who support IT. The policy needs to consider what access each person has not only for when things go wrong but in the event of the loss of the employee.
There are four classifications of threats that a security policy is required to look at. First is natural threats. Here in Chicago the threat of a tornado or snow storm is highly likely and can cause a disaster our security policy needs to issue a recovery from. However by being in Chicago the threat of tidal wave and hurricane are non-existent.
The next threat comes from the human element. The largest threat comes from insiders, such as the uneducated insiders who share passwords or are susceptible to social engineering. The next threat group is hackers, those on the outside who want to get in and are looking for holes in the system to take advantage of. The criminal element is the group of insiders and hackers who stand to gain a financial reward for breaking the security of the system. Competing companies can take advantage of security holes to get a step up on what the organization is planning on doing next. The lower risk categories of human threat comes from terrorist and foreign governments. In these cases consideration has to be made that someone may try and bring down what the network is controlling, such as a power grid or the wireless cell phone system.
Then the security policy needs to be concerned about environment factors. The best example of examining this area is to look at the storage of magnetic media being near to a river bed where water could cause data loss or high tension wires where the resulting EMF (electro-magnetic field) could cause data corruption.
Finally there is the technical threats. Two common technical threats is obsolescence and badly manufactured equipment. In both cases, if the technology that is used is no longer available is it possible to get these functions up and running on a modern system?
Security experts rate the likelihood of an attack as the sum of the type of threat plus the vulnerability. Some ways to reduce vulnerabilities are to keep software current. We have seen Microsoft issue patches to try and stay a step ahead of the attack from viruses and worms. A security policy needs to be adapted to keep up with the current security advisories and a strong policy will keep track of the published vulnerability listings and how they were addressed so such vulnerabilities aren't introduced later on.
A safeguard has a classification in each of the three categories:
Prevent vs. Detect
- prevent keeps an incident from occurring
- detect logs an incident so it can be addressed or correct a future incident from happening
Technical vs. Non-technical
- technical is a solution, implemented in the technology to prevent an incident or attack
- non-technical is a human implementation to locate and address any incident or attack
Reduce likelihood vs. Reduce impact
- reduce likelihood is a solution that makes it harder for an attack to take place
- reduce impact is a solution that focuses on the recovery after an incident or attack occurred
In addition to these safeguards an increase to security can be done by either evaluating existing controls or proposing new controls. One such example is creating or modifying a password policy to strengthen access control.
For the purpose of discussing the likelihood of an incident can be expressed in one of three ways:
- high, medium or low
- a likely number of occurrences in a time period
- a probability of occurrence in a give time period
For illustrated graphics of these topics consult NIST publication 800-12.
A proper security policy needs to also consider the outcome if an incident is to take place. In the event something does happen, how bad will it be? In creating and implementing security one also needs to know what will be lost if an attack is successful. For some organizations these consequences can be far more costly then terms of data or infrastructure loss. One such attack was the successful release of consumer information from a credit reporting agency.
Let's say a bank manager is justifying the expense of an armed guard when there have been no robberies at the bank. Are there no robberies because no one is trying to rob the bank or is it because the armed guard keeps that element away. Proper risk mitigation should include a cost benefit analysis, that is am I getting enough from the expense to be worth it? In the cost benefit analysis one needs to determine the cost of implementing a control and the cost of not implementing the control. Which controls are we talking about in IT security? The seven controls current available are policy, management, business continuity, incident response, education training and awareness, identification and authentication, and cryptography.
Management control looks at two areas. First, are the people at the top practicing security? For security in an organization to be successful all the workers up the the CEO must practice security. The second area is staffing the security area of the IT department. Is this person a security professional? In several organizations the person placed in this position specifically so the company can say they have someone in this position. The boss walking the floor and calling out "hey you" does not qualify a person to be a security professional.
The business continuity control assumes that if an incident occurs normal operations may be significantly interrupted. Here we have to look at what happens, how fast does it happen and where does it happen. By understand what could be disrupted during a disaster it becomes easier to figure out how to get thinks operational again quickly in the recovery phase.
Incident Response normally includes both technical and non-technical actions. This control also operates in the safeguards of detective and reduce impact when an incident occurs. Incident response also needs to include successful attacks that do not cause a business interruption. For these attacks one must have a good audit system that can be analyzed and locate anomalies in a timely manner.
Security Education, Training and Awareness (SETA) is a process that makes sure everyone understands the security policy and how to act accordingly when an incident occurs. Security Education tells us the why we have a security policy, the training tells us the how to act according to the policy and the awareness tells us the what that will happen if an incident occurs or a policy is violated. This control can be put in place by simply having new employees read the security policies so they are aware that they exist and have an idea where to turn for reference when an incident occurs.
Identification is the presentation of claimed ID. Authentication is the validation of claimed ID. There are three techniques used for authentication: something the user knows, something the user has or something the user is. Each one of these has an inherit weakness that can compromise the system. Something the user knows is a password, however these are easily forgotten and in some cases shared. Something the user has is a token or access card, however these can be lost and in some cases duplicated. Something the user is refers to biometric readers which are currently pricey and in the cases of cuts on the finger tips or a person with a cold doing voice authentication, these can falsely block a person with legitimate access. The ATM banking system is stronger because it combines two items: something the user has which is the card and something the user knows which is the pin number. Sadly online banking in the US requires only a password.
Cryptography is a technical tool used to render data accessible to a select group of people. Not only does it provide data confidentiality but the public key system also provides integrity, a validation that no one has altered the data.
The security policy itself is one of the most important yet least implemented concepts in Information Security. In most cases it is non-technical but where policies can be implemented in the system they are. Policies are also designed to prevent incidents from occurring.
The security policy is a document that defines the security program and states who is in charge of the policy. It contains issue specific policies such as passwords and logging on from home as well as system specific policies such as when dealing with a web server or new accounting software.
When generating a security policy the document needs to specify a clear purpose, the issues and the systems the policy is addressing. It must also specify the role and responsibilities of the employees to practice the procedures outlined in the policy. Compliance also needs to be specified so everyone has an understanding of what will happen when the policy is not followed. Policies are supported by standards, guidelines and procedures.
Audit Trails (Log Files)
Most applications and servers generate log files. Many of these log files do not get checked as they can be used to locate the possibility of an attack or incident. These log files contain the address of the attempted connection which can find the origin of attack. Hackers can circumvent this by using IP spoofing or drone machines to carry out the attack. Since the log files record the history of connections and what actions have been carried out over the connections these should be encrypted to prevent attackers from modifying the logs.
The NIST website nist.gov contains documents which can be found under the products & services area in the publications section.
NIST Publication 800-12 is an introduction to Information Security
NITS Publication 800-30 is the risk management guide
NIST Publication 800-29 is FIPS
At sans.org you can find sample policies which originated from Cisco Systems.
At cert.org you can find vulnerability lists.
Wolffy's Over The EdgePower of Progress Back to School Randomness What In the World Happened To You? 8th Grader Game Coder When Hobbies Take Over Blackout: The Great Disconnect Different Is Awesome