7 This could happenHardware/data theftSniffing, break ins.
8 Risk Analysis and Assessments Know your risksHave security policy and contingency plansPerform audits and assessments (penetration testing, security auditing)Update current policy and planNever ending cycle of process
9 Defense Planning Make ready for the worst Layered defense Security policyContingency plansDisaster recoveryLayered defenseDefense in depth strategies
10 Security Policy Security Policies Guidelines Security Policy Revision Best Practice GuidelinesSecurity Policy Templates
12 Who and What to TrustTrust 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 problemsToo little trust may make it difficult to find and keep employeesHow 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 don’t 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 impracticalone bad apple can ruin the whole barrelTrust no one at no time:most restrictive, but also impracticaldifficult to staff positionsTrust some people some of the time:exercise caution in amount of trust givenaccess is given out as neededtechnical controls are needed to ensure trust is notviolated
15 Why the Political Turmoil? People view policies as:an impediment to productivitymeasures to control behaviorPeople have different views about the needfor security controls.People fear policies will be difficult to followand implement.Policies affect everyone within theorganization.
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 theofficial policy interpreter.Decide on the scope and goals of the policy.Scope should be a statement about who iscovered by the policy.Decide on how specific to make the policy.not meant to be a detailed implementation planDon’t include facts which change frequently
18 The Policy Design Process A sample of people affected by the policyshould be provided an opportunity to reviewand comment.A sampling of the support staff effected bypolicy should have an opportunity to review it.Incorporate policy awareness as a part ofemployee orientation.Provide a refresher overview course on policiesonce or twice a year.
19 Basic Policy Requirements Policies must:be implementable and enforceablebe concise and easy to understandbalance protection with productivityPolicies should:state reasons why policy is neededdescribe what is covered by the policiesdefine contacts and responsibilitiesdiscuss how violations will be handled
20 Level of Control Security needs and culture play major role. Security policies MUST balance level ofcontrol with level of productivity.If policies are too restrictive, people will findways to circumvent controls.Technical controls are not always possible.You must have management commitment onthe 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/updateSome policies appropriate for every site, others arespecific to certain environments.Some key policies:acceptable useremote accessinformation protectionperimeter securitybaseline 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 arenot their own, but are accessible to them.Should state level of acceptable usage for electronicmail, internet news and web access.Should discuss acceptable non-business uses of theresources.
24 Remote Access Policy Outlines and defines acceptable methods of remotely connecting to the internal network.Essential in large organization where networksare geographically dispersed and even extendinto the homes.Should cover all available methods to remotelyaccess internal resources:dial-in (SLIP, PPP)isdn/frame relaytelnet/ssh access from internetcable modem/vpn/DSL
25 Some Elements Should define who can have remote access. Should define what methods are allowed for remoteaccess.Should discuss who is allowed to have high-speedremote access such as ISDN, frame relay or cablemodem.extra requirementsappropriate useShould discuss any restrictions on data that can beaccessed remotely.
26 Information Protection Policy Provides guidelines to users on theprocessing, storage and transmission ofsensitive information.Main goal is to ensure information is appropriately protected from modification or disclosure.May be appropriate to have new employeessign 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 circumstancesnon-disclosure agreementsShould define how sensitive information is tobe stored and transmitted (encrypted, archivefiles, uuencoded, etc).Should define on which systems sensitiveinformation 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 removedfrom systems and storage devices:degaussing of storage mediascrubbing of hard drivesshredding of hardcopy outputShould discuss any default file and directorypermissions defined in system-wide configurationfiles.
29 The Perimeter Security Policy Describes, in general, how perimeter securityis maintained.Describes who is responsible for maintainingit.Describes how hardware and softwarechanges to perimeter security devices aremanaged and how changes are requestedand approved.
30 Some Elements Should discuss who can obtain privileged access to perimeter security systems.Should discuss the procedure to request aperimeter device configuration change and howthe request is approved.Should discuss who is allowed to obtaininformation regarding the perimeterconfiguration and access lists.Should discuss review cycles for perimeterdevice system configurations.
31 Virus Protection and Prevention Policy Provides baseline requirements for the use ofvirus protection software.Provides guidelines for reporting and containingvirus infections.Provides guidelines for several levels of virusrisk.Should discuss requirements for scanningattachments.Should discuss policy for the download andinstallation of public domain software.
32 Virus Protection and Prevention Policy Should discuss frequency of virus data file updates.Should discuss testing procedures forinstallation of new software.
33 Password Policy Provides guidelines for how user level and system level passwords are managed andchanged.Discusses password construction rules.Provides guidelines for how passwords areprotected from disclosure.Discusses application development guidelinesfor when passwords are needed.Discusses the use of SNMP community stringsand pass-phrases.
34 Other Important Policies A policy which addresses forwarding ofto offsite addresses.A policy which addresses wireless networks.A policy which addresses baseline lab securitystandards.A policy which addresses baseline routerconfiguration parameters.A policy which addresses requirements forinstalling devices on a dirty network.
35 Security Procedures Policies only define "what" is to be protected. Procedures define "how" to protect resources andare the mechanisms to enforce policy.Procedures define detailed actions to take forspecific incidents.Procedures provide a quick reference in times ofcrisis.Procedures help eliminate the problem of a singlepoint of failure (e.g., an employee suddenlyleaves or is unavailable in a time of crisis).
36 Configuration Management Procedure Defines how new hardware/software is testedand installed.Defines how hardware/software changes aredocumented.Defines who must be informed whenhardware and software changes occur.Defines who has authority to make hardwareand 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 anddocumented.
38 Incident Handling Procedure Defines how to handle anomaly investigationand intruder attacks.Defines areas of responsibilities for membersof the response team.Defines what information to record and track.Defines who to notify and when.Defines who can release information and theprocedure for releasing the information.Defines how a follow-up analysis should beperformed and who will participate.
39 Policy Resources RFC2196 - The site security procedures handbook Obsoletes rfc1244 as of 09/1997Some useful web sites:
40 Recap Policies are a crucial part of the infrastructure. Trust is frequently an issue.Key policies:acceptable use policyremote access policyinformation protection policyperimeter security management policyKey procedures:CM procedureincident 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 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.
53 The 'We need YOU' Technique Security Newsletter<Company Name> Security NewsletterIssue 1 - MM.DD.YYYYphone:Ext. 00001.Upcoming Events02.Security Article03.What is...?04.Ask us05.Security Resources06.ContactsThe 'We need YOU' Technique
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 SecurityAudits should be conducted on timely basisFull 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 SecurityThe 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 SecurityThe 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 SecurityIt 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 continuedA 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 Handlingstaff 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 BackupsDisaster 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 OthersWeb SecurityCryptography
65 Short Guide to Developing Security Policies Security policies should cover:Encryption policyUse & ownership policyAnalog line/modem/isdn/Dial in access policyAntivirus policyAudit policyDMZ/ test lab policyApplications ( /instant messenger/insecure internet links) policyExtranet policy
66 Short Guide to Developing Security Policies Security policies should cover:Risk assessment policyRemote access policyRouter policyServer policyVPN policyWireless policyMonitoring policy
67 Short Guide to Developing Security Policies Some general websites with information security policies:
68 Training Example? :Advanced Intrusion Response Types of vulnerabilitiesWhat happens when a hacker attacks (spotting an intruder)How to perform live and post-mortem investigationsHow to gather evidence for prosecutorial purposes (and legalities)How to find and eliminate backdoors left behind by an intruderHow to determine what information has been compromisedHow to restore the systemHow 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 NewsletterThe 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