1. Network Security Workshop BUSAN 2003
　Rahmat Budiarto

2. Network Security-Overview
Why?
Risks.

3. This could happen
Website defacement

4. This could happen Dns spoofing
Sept. 28th national DNS spoofing in China
If there is “minghui” anywhere in the URL string, the DNS server will return

5. This could happen
Full access from outside source

6. This could happen
Worm / virus attack

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 Layered defense
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

11. Security Policies Guidelines
Security Policy (1)
Security Policies Guidelines

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 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 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
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
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
Some useful web sites:

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 Policies Revision
Security Policy (2)
Security Policies Revision

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.

49. Security Policy (2)
Implementing the
policy

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 Newsletter
Issue 1 - MM.DD.YYYY
phone:
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)
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

64. Security Policy Templates

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 ( /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:

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.

70. Conclusion

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 You