Embed Size (px)
Citation preview
2
Network Security-OverviewNetwork Security-Overview
Why? Risks.
3
This could happenThis could happen
Website defacement
4
This could happenThis could happen
Dns spoofing Sept. 28th 2002 -
national DNS spoofing in China
If there is “minghui” anywhere in the URL string, the DNS server will return 64.33.88.161
5
This could happenThis could happenFull access from outside source
6
This could happenThis could happen
Worm / virus attack
7
This could happenThis could happen
Hardware/data theft Sniffing, break ins.
8
Risk Analysis and AssessmentsRisk 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 PlanningDefense Planning
Make ready for the worst– Security policy– Contingency plans– Disaster recovery
Layered defense Defense in depth strategies
10
Security PolicySecurity Policy
Security Policies Guidelines Security Policy Revision Best Practice Guidelines Security Policy Templates
11
Security Policy (1) Security Policy (1)
Security Policies GuidelinesSecurity Policies Guidelines
12
Who and What to TrustWho 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)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 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– Don’t 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 configurationfiles.
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 andPrevention 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
41
Security Policy (2) Security Policy (2)
Security Policies Security Policies RevisionRevision
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.
49
Security Policy (2) Security Policy (2)
Implementing the Implementing the policypolicy
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
Security Newsletter– <Company Name> Security Newsletter– Issue 1 - MM.DD.YYYY– http://company.com/security/– email: [email protected]– phone: 123-456-789– 987-654-321 Ext. 000– 01.Upcoming Events– 02.Security Article– 03.What is...?– 04.Ask us– 05.Security Resources– 06.Contacts
The 'We need YOU' Technique
54
Security Policy (3) Security Policy (3)
Best Practice Best Practice GuidelinesGuidelines
55
Best Practice GuidelinesBest 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 GuidelinesBest 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 GuidelinesBest 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 GuidelinesBest 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 GuidelinesBest 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 GuidelinesBest 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 GuidelinesBest Practice Guidelines
Others– Web Security
– Cryptography
64
Security Policy (4) Security Policy (4)
Security Policy Security Policy TemplatesTemplates
65
Short Guide to Developing Short Guide to Developing Security PoliciesSecurity 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 Short Guide to Developing Security PoliciesSecurity 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 Short Guide to Developing Security PoliciesSecurity 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.htmlhttp://irm.cit.nih.gov/security/sec_policy.htmlhttp://w3.arizona.edu/~security/pandp.htmhttp://secinf.net/ipolicye.htmlhttp://ist-socrates.berkeley.edu:2002/pols.htmlhttp://www.ruskwig.com/security_policies.htmhttp://razor.bindview.com/publish/presentations/InfoCarePart2.htmlhttp://www.jisc.ac.uk/pub01/security_policy.html
70
ConclusionConclusion
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
73
Thank YouThank You
