7 This could happen Hardware/data theft Sniffing, break ins.
8 Risk Analysis and Assessments Know your risks Have security policy and contingency plans Perform audits and assessments (penetration testing, security auditing) Update current policy and plan Never ending cycle of process
9 Defense Planning Make ready for the worst –Security policy –Contingency plans –Disaster recovery Layered defense Defense in depth strategies
10 Security Policy Security Policies Guidelines Security Policy Revision Best Practice Guidelines Security Policy Templates
12 Who and What to Trust Trust is a major principle underlying the development of security policies. Initial step is to determine who gets access. Deciding on level of trust is a delicate balancing act. Too much trust may lead to eventual security problems Too little trust may make it difficult to find and keep employees How much should you trust resources or people?
13 Who and What to Trust (cont) Trust is a central theme in many policies. Some policies may not be written because there is trust that people will do the right thing. Then on the other hand, some policies are needed because we know people dont always do the right thing. Ideally you want to trust all resources, but that is unrealistic. Buggy hardware and software are common place. Try to implement controls and procedures to minimize the impact when a failure does occur. Trust of employees and users develops over time. Different categories of employees should be trusted at different levels. Ensure level of access is commensurate with level of trust.
14 Possible Trust Models Trust everyone all of the time: –easiest to enforce, but impractical –one bad apple can ruin the whole barrel Trust no one at no time: –most restrictive, but also impractical –difficult to staff positions Trust some people some of the time: –exercise caution in amount of trust given –access is given out as needed –technical controls are needed to ensure trust is not violated
15 Why the Political Turmoil? People view policies as: –an impediment to productivity –measures to control behavior People have different views about the need for security controls. People fear policies will be difficult to follow and implement. Policies affect everyone within the organization.
16 Who Should Be Concerned? Users - policies will affect them the most. System support personnel - they will be required to implement, comply with and support the policies. Managers - they are concerned about protection of data and the associated cost of the policy. Company lawyers and auditors - they are concerned about company reputation, responsibility to clients/customers.
17 The Policy Design Process Choose the policy development team. Designate a person or body to serve as the official policy interpreter. Decide on the scope and goals of the policy. –Scope should be a statement about who is covered by the policy. Decide on how specific to make the policy. –not meant to be a detailed implementation plan –Dont include facts which change frequently
18 The Policy Design Process A sample of people affected by the policy should be provided an opportunity to review and comment. A sampling of the support staff effected by policy should have an opportunity to review it. Incorporate policy awareness as a part of employee orientation. Provide a refresher overview course on policies once or twice a year.
19 Basic Policy Requirements Policies must: –be implementable and enforceable –be concise and easy to understand –balance protection with productivity Policies should: –state reasons why policy is needed –describe what is covered by the policies –define contacts and responsibilities –discuss how violations will be handled
20 Level of Control Security needs and culture play major role. Security policies MUST balance level of control with level of productivity. If policies are too restrictive, people will find ways to circumvent controls. Technical controls are not always possible. You must have management commitment on the level of control.
21 Policy Structure Dependent on company size and goals. One large document or several small ones? –smaller documents are easier to maintain/update Some policies appropriate for every site, others are specific to certain environments. Some key policies: –acceptable use –remote access –information protection –perimeter security –baseline host/device security
22 The Acceptable Use Policy Discusses and defines the appropriate use of the computing resources. Users should be required to read and sign AU policy as part of the account request process. A key policy that all sites should have.
23 Some Elements Should state responsibility of users in terms of protecting information stored on their accounts. Should state if users can read and copy files that are not their own, but are accessible to them. Should state level of acceptable usage for electronic mail, internet news and web access. Should discuss acceptable non-business uses of the resources.
24 Remote Access Policy Outlines and defines acceptable methods of remotely connecting to the internal network. Essential in large organization where networks are geographically dispersed and even extend into the homes. Should cover all available methods to remotely access internal resources: –dial-in (SLIP, PPP) –isdn/frame relay –telnet/ssh access from internet –cable modem/vpn/DSL
25 Some Elements Should define who can have remote access. Should define what methods are allowed for remote access. Should discuss who is allowed to have high-speed remote access such as ISDN, frame relay or cable modem. –extra requirements –appropriate use Should discuss any restrictions on data that can be accessed remotely.
26 Information Protection Policy Provides guidelines to users on the processing, storage and transmission of sensitive information. Main goal is to ensure information is appropriately protected from modification or disclosure. May be appropriate to have new employees sign policy as part of their initial orientation. Should define sensitivity levels of information.
27 Some Elements Should define who can have access to sensitive information. –need-to-know. –special circumstances –non-disclosure agreements Should define how sensitive information is to be stored and transmitted (encrypted, archive files, uuencoded, etc). Should define on which systems sensitive information can be stored.
28 Some Elements Should discuss what levels of sensitive information can be printed on physically insecure printers. Should define how sensitive information is removed from systems and storage devices: –degaussing of storage media –scrubbing of hard drives –shredding of hardcopy output Should discuss any default file and directory permissions defined in system-wide configuration files.
29 The Perimeter Security Policy Describes, in general, how perimeter security is maintained. Describes who is responsible for maintaining it. Describes how hardware and software changes to perimeter security devices are managed and how changes are requested and approved.
30 Some Elements Should discuss who can obtain privileged access to perimeter security systems. Should discuss the procedure to request a perimeter device configuration change and how the request is approved. Should discuss who is allowed to obtain information regarding the perimeter configuration and access lists. Should discuss review cycles for perimeter device system configurations.
31 Virus Protection and Prevention Policy Provides baseline requirements for the use of virus protection software. Provides guidelines for reporting and containing virus infections. Provides guidelines for several levels of virus risk. Should discuss requirements for scanning email attachments. Should discuss policy for the download and installation of public domain software.
32 Virus Protection and Prevention Policy Should discuss frequency of virus data file updates. Should discuss testing procedures for installation of new software.
33 Password Policy Provides guidelines for how user level and system level passwords are managed and changed. Discusses password construction rules. Provides guidelines for how passwords are protected from disclosure. Discusses application development guidelines for when passwords are needed. Discusses the use of SNMP community strings and pass-phrases.
34 Other Important Policies A policy which addresses forwarding of email to offsite addresses. A policy which addresses wireless networks. A policy which addresses baseline lab security standards. A policy which addresses baseline router configuration parameters. A policy which addresses requirements for installing devices on a dirty network.
35 Security Procedures Policies only define "what" is to be protected. Procedures define "how" to protect resources and are the mechanisms to enforce policy. Procedures define detailed actions to take for specific incidents. Procedures provide a quick reference in times of crisis. Procedures help eliminate the problem of a single point of failure (e.g., an employee suddenly leaves or is unavailable in a time of crisis).
36 Configuration Management Procedure Defines how new hardware/software is tested and installed. Defines how hardware/software changes are documented. Defines who must be informed when hardware and software changes occur. Defines who has authority to make hardware and software configuration changes.
37 Data Backup and Off-site Storage Procedures Defines which file systems are backed up. Defines how often backups are performed. Defines how often storage media is rotated. Defines how often backups are stored off- site. Defines how storage media is labeled and documented.
38 Incident Handling Procedure Defines how to handle anomaly investigation and intruder attacks. Defines areas of responsibilities for members of the response team. Defines what information to record and track. Defines who to notify and when. Defines who can release information and the procedure for releasing the information. Defines how a follow-up analysis should be performed and who will participate.
39 Policy Resources RFC2196 - The site security procedures handbook –Obsoletes rfc1244 as of 09/1997 –http://www.ietf.org/rfc/rfc2196.txt?Number=2196 Some useful web sites: –http://www.gatech.edu/itis/policy/usage/contents.html –http://csrc.nist.gov/isptg/
40 Recap Policies are a crucial part of the infrastructure. Trust is frequently an issue. Key policies: –acceptable use policy –remote access policy –information protection policy –perimeter security management policy Key procedures: –CM procedure –incident handling procedure
42 Revising The Security Policy The purpose of this section is to guide you through the process of revising your security policy, as well as to ensure its effectiveness by closely reviewing several critical factors for its lasting success.
43 Let us assume you have already created or revised the security policy, BUT… How does it look to staff members? Do they understand each of the terms, devices or the applications mentioned? How clear and precise is your policy; is it maybe a little too detailed, or precise that people loose sight of what it is trying to convey. Or is it just the opposite, missing the point entirely and/or not covering any of the important? issues?
44 Define the purpose of the security policy from the very beginning; does it apply to the information assets of the whole company, or is just created to cover a particular division or department. the risks can be tremendously reduced if everyone realizes that "security is everyone's responsibility".
45 Each of the assets needs to be precisely described to include, among others, items such as hardware, software, personnel, acceptable Internet use, etc.
46 If your company has already created a security policy, don't waste valuable time and resources building a new one; just rebuild and update the current one instead, thus saving a lot of research time.
47 You frequently need to monitor and update your security policy as new threats and technologies appear almost every day. Try to always keep up to date with the latest security problems (and the related remedies) in order to have the information assets of your company protected to a reasonable degree.
48 Your policy must clearly state how the Information Security Office (ISO) can be contacted (if there is one, otherwise, a relevant contact person); staff need to know with whom they should get in touch when they have questions, doubts, or have detected any suspicious activity. You should at least have a (cell)phone and an e- mail address available for this point of contact.
50 When the security policy is all drawn up, revised, updated and agreed upon, the implementation process will follow. This is usually harder than the creation of the policy itself, due the fact that at this stage you also need to coach and educate your staff to behave in a "secure" manner, following each of the core elements pointed in the formal security policy.
51 A proper implementation requires not only educating staff on each of the core elements flagged as critical in the formal Security Policy, but also changing their role in the effort to protect critical company data.
52 creation process of a basic Security Awareness Program, various innovative and interesting ways of educating your staff, using user-friendly & informal lines of communication between the Information Security Office (ISO) members and your employees.
54 Security Policy (3) Best Practice Guidelines
55 Best Practice Guidelines Bad: "We have hardened our hosts against attack." Good: "We have applied all security patches for Windows 2000 as of 8/31/2000 to our servers. Our Administrator is tasked with keeping up-to-date on current vulnerabilities that may affect our environment, and our policy is to apply new patches during our maintenance period (2300hrs, Saturday) every week. Critical updates are implemented within 24 hours. A complete list of applied patches is available to X."
56 Best Practice Guidelines General Security –Audits should be conducted on timely basis –Full documentation of network diagram environment, relationship any other relevant networks, with a full data flowchart that details where data resides, the applications that manipulate it, should be available.
57 Best Practice Guidelines Physical Security –The equipment must be located in a physically secure facility, which requires badge access at a minimum. –The infrastructure must be located in a locked cage- type environment and properly guarded. –Entrance authorization to secure area and final say on who is authorized to enter any locked physical environment. –The ISP must disclose who amongst their personnel will have access and to what limit.
58 Best Practice Guidelines Network Security –The application environment must use separate hosts, and separate infrastructure. –If connection is via a private circuit then that circuit must terminate on the extranet, and the operation of that circuit will come under the procedures and policies. –Otherwise, if the data will go over a public network, appropriate firewalling technology must be deployed. Any traffic between public and private circuit must be protected (cryptography) and authenticated.
59 Best Practice Guidelines Host Security –It must be decided how and to what extent the hosts (Unix, NT, etc.) running the application infrastructure have been hardened against attack. Documentation on the process should be existent. –A listing of current patches on hosts, including host OS patches, web servers, databases, and any other material application should be produced an kept track of. –Information on how and when security patches will be applied must be decided. Also how does the ISP keep up on security vulnerabilities, and what is the policy for applying security patches?
60 Best Practice Guidelines Host Security continued –A processes for monitoring the integrity and availability of those hosts should be existent. –password policy for the infrastructure, including minimum password length, password generation guidelines, and how often passwords are changed. –User authentication? (e.g., LDAP, Netegrity, Client certificates.) –Account generation, maintenance and termination process, for both maintenance as well as user accounts.
61 Incident Handling staff should be able to define a potential security problem, you should be establishing the rules for the course of action to take in case of an incident. In your policy you must clearly state what must be done in various situations; the main idea here should be to minimise and limit damage. Staff should be made aware who is responsible for handling problems, and whom they should contact as soon as they suspect a potential security problem.
62 System Backups Disaster recovery (DR) plans are essential for the continuity of the business as well as the proper functionality of the current processes. Sooner or later you will inevitably face the problem where a system crashes, no matter of the OS used, but this can be dealt with promptly, if proper backup procedures and disaster recovery plans are in place. You will have to define the assets that must be backed up on a regular basis, the responsible individuals, best practices and procedures, as well as where the backups should be stored, i.e. a fireproof safe, vault, off-site, etc.
63 Best Practice Guidelines Others –Web Security –Cryptography
65 Short Guide to Developing Security Policies Security policies should cover: –Encryption policy –Use & ownership policy –Analog line/modem/isdn/Dial in access policy –Antivirus policy –Audit policy –DMZ/ test lab policy –Applications (email/instant messenger/insecure internet links) policy –Extranet policy
66 Short Guide to Developing Security Policies Security policies should cover: –Risk assessment policy –Remote access policy –Router policy –Server policy –VPN policy –Wireless policy –Monitoring policy
67 Short Guide to Developing Security Policies Some general websites with information security policies: http://www.security.kirion.net/securitypolicy/ http://www.network-and-it-security-policies.com/ http://www.brown.edu/Research/Unix_Admin/cuisp/ http://iatservices.missouri.edu/security/ http://www.utoronto.ca/security/policies.html http://irm.cit.nih.gov/security/sec_policy.html http://w3.arizona.edu/~security/pandp.htm http://secinf.net/ipolicye.html http://ist-socrates.berkeley.edu:2002/pols.html http://www.ruskwig.com/security_policies.htm http://razor.bindview.com/publish/presentations/InfoCarePart2.html http://www.jisc.ac.uk/pub01/security_policy.html http://www.security.kirion.net/securitypolicy/ http://www.network-and-it-security-policies.com/ http://www.brown.edu/Research/Unix_Admin/cuisp/ http://iatservices.missouri.edu/security/ http://www.utoronto.ca/security/policies.html http://irm.cit.nih.gov/security/sec_policy.html http://w3.arizona.edu/~security/pandp.htm http://secinf.net/ipolicye.html http://ist-socrates.berkeley.edu:2002/pols.html http://www.ruskwig.com/security_policies.htm http://razor.bindview.com/publish/presentations/InfoCarePart2.html http://www.jisc.ac.uk/pub01/security_policy.html
68 Training Example? :Advanced Intrusion Response –Types of vulnerabilities –What happens when a hacker attacks (spotting an intruder) –How to perform live and post-mortem investigations –How to gather evidence for prosecutorial purposes (and legalities) –How to find and eliminate backdoors left behind by an intruder –How to determine what information has been compromised –How to restore the system –How to coordinate with other sites and deal with law enforcement.
69 Training A Security Policy Framework. Policies define appropriate behavior.. Policies set the stage in terms of what tools and procedures are needed.. Policies communicate a consensus.. Policies provide a foundation for HR action in response to inappropriate behavior.. Policies may help prosecute cases.
71 The aim is to explore the process of building and implementing a successful Information Security Policy in detail, as well as giving various recommendations for the development of a Security Awareness Course.
72 The security within any organization starts with building a Security Policy, a centralized, evolving document defining what is allowed and what is not. "Best Practices" sections on various security threats, as well as a sample Security Newsletter The implementation process requires constant monitoring of Internet Threats, along with the measurement of staff knowledge and awareness levels to ensure that there is a continuous improvement in their level of knowledge