jump to navigation

Initial Site Survey Guidelines August 9, 2008

Posted by timsteiner in Information Security.
Tags: , , , , , , ,
add a comment

Initial Site Survey

  • Are passwords difficult to crack?
  • Are there access control lists (ACLs) in place on network devices to control who has access to shared data?
  • Are there audit logs to record who accesses data?
  • Are the audit logs reviewed?
  • Are the security settings for operating systems in accordance with accepted industry security practices?
  • Have all unnecessary applications and computer services been eliminated for each system?
  • Are these operating systems and commercial applications patched to current levels?
  • How is backup media stored? Who has access to it? Is it up-to-date?
  • Is there a disaster recovery plan? Have the participants and stakeholders ever rehearsed the disaster recovery plan?
  • Are there adequate cryptographic tools in place to govern data encryption, and have these tools been properly configured?
  • Have custom-built applications been written with security in mind?
  • How have these custom applications been tested for security flaws?
  • How are configuration and code changes documented at every level? How are these records reviewed and who conducts the review?

Pre-Audit Homework

Before the computer security auditors even begin an organizational audit, there’s a fair amount of homework that should be done. Auditors need to know what they’re auditing. In addition to reviewing the results of any previous audits that may have been conducted, there may be several tools they will use or refer to before. The first is a site survey. This is a technical description of the system’s hosts. It also includes management and user demographics. This information may be out of date, but it can still provide a general framework. Security questionnaires may be used as to follow up the site survey. These questionnaires are, by nature, subjective measurements, but they are useful because they provide a framework of agreed-upon security practices. The respondents are usually asked to rate the controls used to govern access to IT assets. These controls include: management controls, authentication/access controls, physical security, outsider access to systems, system administration controls and procedures, connections to external networks, remote access, incident response, and contingency planning.

Site surveys and security questionnaires should be clearly written with quantifiable responses of specific requirements. They should offer a numerical scale from least desired (does not meet requirements) to most desired (meets requirements and has supporting documentation). Both should include electronic commerce considerations if appropriate to the client organization. For instance, credit card companies have compliance templates listing specific security considerations for their products. These measure network, operating system, and application security as well as physical security.

Auditors, especially internal auditors, should review previous security incidents at the client organization to gain an idea of historical weak points in the organization’s security profile. It should also examine current conditions to ensure that repeat incidents cannot occur. If auditors are asked to examine a system that allows Internet connections, they may also want to know about IDS/Firewall log trends. Do these logs show any trends in attempts to exploit weaknesses? Could there be an underlying reason (such as faulty firewall rules) that such attempts are taking place on an ongoing basis. How can this be tested?

Because of the breadth of data to be examined, auditors will want to work with the client to determine the scope of the audit. Factors to consider include: the site business plan, the type of data being protected and the value/importance of that data to the client organization, previous security incidents, the time available to complete the audit and the talent/expertise of the auditors. Good auditors will want to have the scope of the audit clearly defined, understood and agreed to by the client.

Next, the auditors will develop audit plan. This plan will cover how will audit be executed, with which personnel, and using what tools. They will then discuss the plan with the requesting agency. Next they discuss the objective of the audit with site personnel along with some of the logistical details, such as the time of the audit, which site staff may be involved and how the audit will affect daily operations. Next, the auditors should ensure audit objectives are understood.

http://www.securityfocus.com/infocus/1697



White Paper: Legal Liabilities of an IT Professional February 11, 2008

Posted by timsteiner in Research.
Tags: , , , , , , , , , , , , ,
add a comment

Tim Steiner

LES 330

12/05/07

White Paper: Legal Liabilities of an IT Professional

INTRODUCTION

As an IT Security Professional your main focus is to provide confidentiality, integrity, and availability (CIA) of sensitive company and client information. This means that the information is only seen by its intended viewer, it is not tampered with, and available when requested (Bell, G. 2001). This can be a daunting task when faced with vast amounts of information that needs secured. If you overlook something, will you be held liable? What happens if you fail to properly do your job and it results in loss of intellectual property, trade secrets, or your client’s bank account information? Thus, It is important to understand the duty of care that is expected of you as an IT professional in order to avoid legal liability. This is why I have chosen to research the legal liabilities of an IT professional and give a more clear assessment of what standards apply.

OVERVIEW

A professional is defined as a person who, “has more than average skills and abilities.” When a professional is sued they are held to a higher standard than an ordinary person because they are expected to know better. Recognized professionals can be sued for malpractice while ordinary individuals can only be sued for negligence (Professional Negligence, 2007). Furthermore, recognized professionals such as doctors, lawyers, or accountants can be sued for malpractice if they fail to provide a sufficient standard of care and the results are tortuous (Malpractice, 2007). Recognized professions require practitioners to meet certain universal requirements and there is a standard certification process. Because there is no universally agreed upon certification process, there are no clear standards for IT professionals. IT professionals are currently not considered professionals in regards to legal liability and therefore not subject to malpractice lawsuits.

ANALYSIS

Since IT professionals are not subject to malpractice, only negligence suits can be brought against an IT professional. In order to prove negligence the claimant must show that there was a duty of care owed to them and that the duty of care has been breached (Breach of duty in English law, 2007). The claimant bears the burden of proof to show that there was a duty of care owed, and a breach of that duty of care caused some harm to the claimant. The court uses a test to find if the defendant was negligent. This test examines what a reasonable person would have done in the same situation (Roe v Minister of Health, 2007).

Origins

There are several cases that identify the origin of the reasonable person test. In 1837 the famous English tort case, Vaughan v. Menlove, first used the reasonable person test to find if a defendant was liable for negligence (Vaughan v. Menlove, 2007). The 1954 case of Roe v Minister of Health involved proving that a medical professional failed to meet the required duty of care. It was shown that a reasonable medical professional would not have foreseen the subsequent harm and therefore was not liable (Roe v Minister of Health, 2007). These cases set a precedence for negligence suits today.

Evolution

Since the inception of negligence cases there have been many critical changes. In 1957, the Bolam test was introduced after the case of Bolam v Friern Hospital Management Committee showed that a higher duty of care is owed by an individual with skills and abilities in excess of an ordinary person (Bolam Test, 2007). This case first identifies the professional standard of care (Standard of Care, 2007).

Current Applications

Many of the mentioned historical cases are referenced today in modern negligence cases. Currently, the Bolam test is being used to determine whether a doctor is liable for medical malpractice (Bolam Test, 2007). The “hand rule”, or Calculus of Negligence, is used today in the United States to determine the responsibility of a person to take precautions. If the cost to avoid harm is less than the cost of that harm then the precautions should be taken (Calculus of Negligence, 2007). This clearly applies to IT applications. Many precautions are taken by businesses to prevent information security loss. Using the hand rule if the cost of preventing information loss is less than the cost of losing that data, then the precautions should be taken.

ASSESSMENT

Clearly many historic cases, although unrelated in subject matter, are applicable to cyberlaw. Furthermore, many of the same rules of law that apply to written contracts also apply to electronic contracts. The liability of an IT professional is similar to that of any professional. An IT professional has more than average skills and abilities in specific areas, therefore the IT professional will be held to a higher standard than an ordinary individual. At this time there is no universal licensing of IT professionals due to the vast areas of expertise and quickly changing technologies. This is a good thing for IT professionals in terms of legal liability. IT professionals can be held liable for negligence, but not malpractice which poses a much more severe consequence.

CLOSING REMARKS

The IT professional faces many challenges to ensure information is C.I.A. while limiting liability. Liability can not be eliminated but can be mitigated through following good information security practices and procedures. If precautions are used effectively and the hand rule is applied, then risk of negligence is minimal. No policies should be a replacement for good common sense. If the IT professional is actively involved in day to day operations and notices something that could result in a security breach, then it should be addressed immediately. Paying attention to details is essential to all professionals and especially important for IT applications where security is key.

REFERENCES

Bell, G. (2001). Information Security Risk & Assessment. Retrieved December 4, 2007, from http://www.sis.uncc.edu/LIISP/slides01/Greg-Bell.pdf

Roe_v_Minister_of_Health. (2007, December). Wikipedia. Retrieved December 4, 2007, from http://en.wikipedia.org/wiki/Roe_v_Minister_of_Health

Vaughn_v._Menlove. (2007, December). Wikipedia. Retrieved December 4, 2007, from http://en.wikipedia.org/wiki/Vaughn_v._Menlove

Malpractice. (2007, December). Wikipedia. Retrieved December 4, 2007, from http://en.wikipedia.org/wiki/Malpractice

Bolam_Test. (2007, December). Wikipedia. Retrieved December 4, 2007, from http://en.wikipedia.org/wiki/Bolam_Test

Calculus_of_negligence. (2007, December). Wikipedia. Retrieved December 4, 2007, from http://en.wikipedia.org/wiki/Calculus_of_negligence

Breach_of_duty_in_English_law. (2007, December). Wikipedia. Retrieved December 4, 2007, from http://en.wikipedia.org/wiki/Breach_of_duty_in_English_law

1/5

Is Intrusion Detection Important? February 11, 2008

Posted by timsteiner in Research.
Tags: , , , , , , , , , , , , , ,
add a comment

Tim Steiner

SEC-330

Structured External Assignment

Intrusion detection is essential in today’s world of insecure networks and the need for data confidentiality is steadily increasing. Unfortunately there is only a small percentage of small to mid-sized organizations that employ host based or network based intrusion detection systems (IDS). It is no longer enough to just use a firewall and expect the network to be secure. There is a need to see what is going on inside the network and identify potential threats.

Before going any further it is important to understand what an IDS is, and why it is important. An IDS detects attacks against a computer network. The benefits to having an IDS are detecting attacks, enforcing policies, providing an audit trail, and resource justification. An IDS can detect attacks and tell if computer systems have been compromised. Internal behavior can be monitored to ensure compliance with the acceptable use policies. After the attack an audit trail can show how far an attack went and where it came from. An IDS can show just how well the firewall is working and the information on attacks can be used as justification for a firewall upgrade.

In order to decide what type of IDS to employ one must understand how the IDS detects attacks. There are a couple of ways an IDS can detect attacks on the network. Signature detection matches network traffic against a list of known signature attacks. This is effective against known attacks but may not detect newly developed attacks. Anomaly detection works by learning what normal traffic looks like and will then alert you when it sees abnormal traffic. This works great but may be high on false positives. Snort uses primarily signature detection.

Snort is quickly becoming the industry standard for network intrusion detection systems. Furthermore, it is open source and freely available. What really sets Snort apart from other NIDS is Snort’s configurability and ability to be run on multiple platforms. Snort’s configuration files can be fine-tuned to specific network architectures and custom rules can even be made. Another big factor is that Snort is constantly updated with new attack signatures.

Before installing Snort, it is important to consider what resources are to be protected and what kind of bandwidth will be monitored. If the network has a firewall and DMZ, it is common to place the Snort sensor between the DMZ network and the switch facing the internet. Snort puts a network card in promiscuous mode so it sees all network traffic. If the network traffic is too much for one Snort sensor it will drop packets increasing the likelihood of a false negative. It is important to have a Snort system that is fast enough to handle network traffic. If this is not possible multiple Snort sensors can be used. An example would be using separate Snort sensors for each subnet.

Snort can log its output in several ways tcpdump binary, ASCII logging, and logging to a database. Tcpdump binary is very fast but logs data in binary format. “There are 10 kinds of people in the world: those who understand binary data, and those who don’t.” ASCII logging is slower but easier to read. Logging to a database is a great tool for creating easy to read visual reports using additional programs such as ACID (The Analysis Console for Intrusion Detection).

The kinds of information logged are alerts that contain what kind of attack, where it’s coming from, where it’s going, and where to find more information. The actual packets of the attack will record MAC addresses, IP addresses, packet payload, timestamp, and TCP flags. Alerts to watch for are attempted-admin, attempted-user, successful-admin, successful-user, shellcode-detect, suspicious-login, attempted dos, and denial-of-service.

Once Snort is up and logging alerts to a MySQL database, other software can be utilized to see visual reports of the data. ACID is an open source analysis console specifically tailored to Snort. With ACID one can view Snort alerts according to various criteria, use information from security web site such as Bugtraq and ArachNIDS, Put alert information in graphical format, and search functions for all Snort data in the database.

So now the IDS, database, and analysis console is set up and working. Now comes the fun part, the rule set of the IDS must be fine-tuned to reduce false positives and eliminate false negatives. “Tuning Snort is like Goldilocks faced with her choices: start with the bed that’s way too big and then keep refining until its jusssst right.” There are many default rules that may be unnecessary and should be removed to increase efficiency.

In the event of a real attack, an incident response plan is crucial in getting up and running as soon as possible. It’s important to have a plan in place to respond to an attack, find out how far the attacker got, recover from the attack, and learn from the attack so that it won’t happen again. If a real-time attack is identified the attack must be stopped immediately. This can be done by pulling the network plug, or pulling the power cord. Pulling the network cable out is a quick and easy way to knock a logged-in intruder off of the system. Furthermore, it keeps programs running for further investigation and prevents the system from being the launching point of further attacks. Pulling the power cord (not the power switch) is important to preserve evidence for a court case. Using the operating systems shutdown function could cause more harm if the intruder left something behind that is triggered by a shutdown command.

Updating Snort, as with any system, is important to keep the system up to date and patch known exploits. Oinkmaster is a Perl script that downloads updated rules files from Snort.org. Snort updates, modifies, and makes minor changes daily so it can be an overwhelming job to make all the changes by hand. Oinkmaster automates the process.

The designers of Snort knew that it would not be feasible to integrate everything (administration, visualizations, and remote management) into one program. With this in mind they made Snort the best IDS sensor it could be and left the other functions to external programs. This is what makes Snort so configurable but also very intimidating. There are a lot of options to consider before setting up a Snort IDS.

REFERENCES

Scott C. (2004). Snort for Dummies

Intrusion Detection System (2007). Wikipedia. Retrieved October 17, 2007, from http://en.wikipedia.org/wiki/Intrusion-detection_system.

Network Intrusion Detection System (2007). Wikipedia. Retrieved October 17, 2007, from http://en.wikipedia.org/wiki/Nids.

Snort(software) (2007). Wikipedia. Retrieved October 17, 2007, from http://en.wikipedia.org/wiki/Snort_%28software%29.

About Snort (2007). Snort.org. Retrieved October 17, 2007, from http://snort.org/about_snort/

Follow

Get every new post delivered to your Inbox.