How to develop a security policy

1. How to develop a Security Policy
By : Khawar Nehal
Seminar on Network Security
Sponsored by BarbedWire
27 June 2005

2. Topics Covered
●
What is a security Policy
●
Unenforceable Policies
●
Email and web filtering
●
Approaches to Policy Development
●
ACL management based on Policies

3. What is a Security Policy ?
●
Organizations usually have unwritten policies.
●
These are known as tacit policies.
●
Formal Security policy development requires
understanding authority, scope, expiration,
specificity and clarity.
●
Developing and implementing such policies is
not easy.

4. What it does.
●
A security policy establishes what must be done
to protect information stored on computers. A
well written policy contains sufficient definition
of “what” to do so that the “how” can be
identified and measured or evaluated.

5. The big deal of “access control”
●
The problem is that the “network” is designed
and expected to provide access.
●
The lack of control requires allows people to do
things which result in losses or destruction of
valuables of an organization.

6. The big deal of “access control”
●
Access pertains to accessibility, providing
services, performance, and ease of use.
●
Control focuses on denial of unauthorized service
or access, separation, integrity and safety.

7. IT Security Policies
●
IT security policies (including network security
policies) are the foundation, the bottom line, of
information security within an organization. As
such, it is well worth considering a few questions
with respect to them:
●
Are they comprehensive enough?
●
Are they up to date?
●
Do you deliver them effectively ?

8. Example Policy Brief
Each employee of the organization is
responsible for the security and protection of
electronic information resources over which
he or she has control.

9. Before and Now.
Before people used to think that one policy existed.
Which was :
●
Everything is denied except that which is
specifically permitted.
●
Everything is permitted except that which is
specifically denied.
Looks like an ACL doesn't it.

10. Now
The real policy which exists is as follows :
●
Everything is denied except that which is
specifically permitted or that which gets in
anyway.

11. Examples
●
Fragmented packets do not have port numbers in
their headers.
●
A simple firewall cannot decide wether to accept
or reject.

12. Examples
In such ambiguous cases a firewall can
●
Consult the state table to see if the fragment is
part of an existing connection.
●
Buffer the fragment to complete the IP packet
then decide.
●
Let the fragment through and limit speeds of such
packets to reduce DOS attack possibilities.

13. Examples
●
If outbound ICMP unreachables are disabled
then let the fragment through.
●
Drop the packet and make the sender retransmit.

14. Complexity
●
Firewall GUIs may look simple.
●
However there is a large amount of complexity
underneath the simple looking interface.
●
Sometimes we may be granting access when we
are thinking we are applying control.
●
These cases are called unenforcable policies.

15. Unenforceable Policy
●
In the main frame days there used to be policies
like : “no personal use of the organization's
computers”
●
Since 1985 and the times of distributed network
computing. Such policies have become
unenforceable.

16. Email Example
●
You are working on a document and you check
an email then you see that someone sent you a
greeting card. You visit the card site or find
something interesting on google. You forget the
document for over an hour.
●
The policy is written but can not be enforced.

17. Problems with such policies
●
If you have an unenforceable administrative
policy, then people are encouraged to ignore or
push the rules.
●
In fact one reason why cracking is so prevalent is
that any laws against it are virtually
unenforceable, especially because many courts
have ruled that the reconnaissance phase,
scanning, is legal.

18. Another example
●
Report all virus infections.
●
Usually a virus is cleaned and people get on with
life without bothering to report it.
●
With automated monitoring tools the reports can
go from seven manual reports per year to more
than a thousand automated reports.

19. Unusual user questions
●
What if my wife sends me an email ? Is it okay to
read it ?
●
Can I check my stocks at lunch ?

20. Answers
●
Due to such questions, something called a limited
personal use policy is created.
●
Basically this limited use policy states things like
:
●
You may use the computers for personal use.
BUT. Do not ask. Do not tell. Do not send chain
letters, do fund raising, or pass files which cause
useless discussions to start.

21. Content Filtering
●
Client Side content filters have matured but
require a subscription.
●
Proxy server based content filters are a better
solution according.

22. Back to centralization
●
A lot of the problems arising out of the pervasive
computing is that many computers are running
independently.
●
Administrators are reluctant to monitor such a
large number of computers.

23. Back to centralization
●
By centralizing the servers to Web Based
softwares, Email clients, groupware and also
using Terminal servers with centralized
computing, the problem of unenforceable policies
is reduced dramatically.

24. Email Server
●
A web Based central mail server either hosted in
the company or in a third party offers a deterrent
because all employees know that their email can
be monitored.
●
Filtering non company email is easy because
there is only one domain.
●
Domains like yahoo and hotmail can be blocked.

25. Email Server
●
Email is a very large leak of important
confidential documents.
●
This is mainly due to the fact that most
companies do not clearly state that giving
information out is an offence. New people
entering the workforce are use to copyright
violations and do not think of sharing such
information as an offence.

26. Email Server
●
Before an employee has finished his or her tea,
they shall attach any file you request them to and
never remember that they they sent the file.
●
Outlook is a user friendly program which accepts
email from anyone and runs any code embedded
just by reading the email. You do not need to
double click an attachment.

27. HTML Aware Email Clients
●
Companies currently still allow the use of HTML
aware macro extendable programs such as
outlook.
●
What is required are programs which do not
download and execute HTML code whenever an
email is received.
●
Hardly any organization has the need for such
features.

28. Gmail type Javascript
●
Gmail provides the best example of client side
scripting.
●
Their email software is web based and feels like a
local email client for more than 90% of the
world's users.
●
No viruses are possible automatically because the
HTML is opened by server side softwares.

29. Client Side Backups
●
Administrators usually backup their servers and
in an emergency or drill situation do not bother
about data on the client machines.
●
Examples are : The contact list on the marketing
manager's harddisk or the top management's
recent notes.

30. Media Leaks
●
People move data on Floppies, CDRW, Tapes,
Flash drives, even harddisks.
●
Companies usually have a policy that states that
all media needs to be declared, however random
spot checks are rarely done in such places.

31. Business Continuity
●
Examples of lost credit card by Bank of America
on UPS routes exemplifies the need for
encryption of backups.
●
Business continuity requires response times less
than the usual 3 to 5 hours for cold sites to come
back online.

32. Backdoors
●
Modems can breach security.
●
Monitoring of Analog lines is touch.
●
Monitoring the digital lines is better.
●
Even the serial port monitor which is cost
effective can be fooled by XON/XOFF
encodings.
●
Beware of hardware keyloggers disguised as
inductance coils.

33. Proxy Server
●
Content filtering in the proxy server prevents
access to denied sites.
●
If thin clients are used then http tunnels and DNS
tunnels are possible but easily monitorable.
●
Also http tunnels shall be intentional.

34. Applications
●
Virus management and spywares shall be reduced
dramatically because the servers shall be
monitored by the administrators very carefully.
●
Usually heavy work can be done on Linux based
servers while other client can use VNC or other
terminal server protocols like RDP.

35. Policies Change
●
As requirements change, policies change to meet
them.
●
Sooner or later the firewall or content filtering
managers shall have a controversy as to what to
allow or deny.
●
To avoid this problem updated, approved and
signed policies need to be circulated to the ACL
managers.

36. Usual Issues
●
The scope of information security is not organization wide.
●
Some non­central information systems may not be well managed
●
Some third party systems are not appropriately protected
(Example TCS terminals or other service providers terminals)
●
Information security for personal computers is weak
●
Insufficient resources are focused on information security
●
Policy development is not receiving sufficient attention

37. Many approaches
●
There are many approaches to developing
policies.
●
The recommended method these days is a risk
based approach.

38. Risk Based Approach
In the risk based approach :
●
We identify the risk
●
Communicate what is learned to upper
management
●
Update or create the security policy
●
Figure out how to measure compliance to the
policy provided.

39. Identifying Risks
●
What data from a different source used by the
organization shall really hurt if it was not
available ?
●
Find out what the Internet is being currently
being used for. This needs to be done quitely.
●
Since there is no policy, the users are not doing
anything wrong.

40. Keep the users calm.
●
Explain to the users that you are simply trying to
establish a baseline and not get anyone into
trouble.
●
When some users ask why they need to follow a
policy, then a written, signed and dated policy
from upper management is all it takes to get most
people to accept the idea that things need to be
done slightly differently.

41. Communicating Ideas
●
Rule number one of explaining things to upper
management.
●
You need to realize that they do not understand
the obvious differences between ATM & ATM or
DOS & DOS & DDOS.
●
Keep the communication simple, balanced and
fairly consise.

42. Avoid Individual Attacks
●
In the presentation do not mention any person by
name. Management may take that as a personal
attack and dismiss all that you have researched.
●
Keep the tone general.
●
Provide problems found and implications.
●
Provide examples where financial losses were
incurred.

43. Offer Options
●
Provide the management options for managing
the risks.
●
It is probably better to use more than one anti
virus software on the mail server.
●
If management decides to buy only one then
provide enough information for them to be able
to make a reasonable choice.

44. Written copy.
●
Do not present as a discussion only.
●
Provide a written copy to everyone involved in
the process.

45. Leadership Required
●
Hire an information security director to lead the organization wide
efforts to raise information security readiness.
●
Develop and implement an information security plan
●
Develop effective working relationships with
– other central offices
– all branches,
– Suppliers and vendors being interfaced with.
– Assist branches in benefiting from what has already been
accomplished at other branches.
– Develop an organization wide information security forum for
information­sharing and solution­seeking

46. The Problem
●
Software systems fail to
adequately address security
and privacy issues during
analysis & design.

47. Challenges
●
Difficult to apply traditional software
requirements engineering techniques to systems
in which
– policy is continually changing the need to respond to
the rapid introduction of new technologies which may
compromise those policies
– increasing external pressure to publicize one’s
information and security practices
●
Government now requires compliance with laws (e.g. Statebank
Banking Regulations, WTO, Basel II)

48. Addressing the Problem
●
Goal:
– Use effective approaches to ensure security
and privacy requirements coverage
●
Strategy
– apply scenario analysis and goal­driven analysis strategies
– perform risk and impact assessments to ensure system requirements align
with organizational policies
– analyze security and privacy policies
– ensure compliance with governing laws

49. Goal and scenario analyses offer methodical and systematic
approaches both for formulating policy goals and guaranteeing
that a system’s requirements are in compliance with these
policies and users’ values.

50. Common Policy Problems
●
Nonconformance to “standard”
– Organisation for Economic Cooperation & Development
– Federal Trade Commission
– State Bank Regulations.
– Fair Information Practices
●
Ambiguity and misplaced trust
– Policies are difficult to find/interpret
– Failure to implement policy
– Inconsistencies are common

51. Requirements Inspection
●
Inspection artifacts:
– Requirements
– Security policies
– Privacy policies
●
Process:
– Use heuristics to cross­compare requirements, privacy policies and security
policies to identify and resolve conflicts and ambiguities
●
Helps identify inconsistencies across requirements and policies
●
Example:
– Privacy Policy: No sharing of PII w/ 3rd parties
– Requirement: Use PII to complete transaction

52. Potential Relationships and Conflicts
General Relat ionships:
Constrains Item A constrains Item B.
Depends Item A depends upon Item B.
Supports Item A supports (in some manner) Item B.
Operationalizes Item A operationalizes Item B.
Conflict s:
Terminology Complete clash between terminology used within
documentation.
Differences between terminology used within
Ambiguity documentation in which there is a need to qualify or
further refine some term.
Incomplete Ambiguity A specialized form of ambiguity that results from terms
being left out of the documentation.
Potential There exists even the slightest possibility for a conflict to
occur, as the statements are open to misinterpretation.
Definite A conflict will occur if the requirements and policies are
implemented as written.

53. Compliance: Policy Statements &
Requirements
MAINTAIN ENSURE MAINTAIN
member content member data
entrance to visibility to history (for user
server members customization)
only
Authentication is required for access
to the commerce Web server.
All member account information will
be kept confidential and used for
#
internal business purposes only.
The firewall should be configured to
limit data access to authorized
member users.

54. Challenges
●
How can we guarantee:
– policy complies with law?
– system requirements comply with policy?
– information handling adheres to policy and system requirements?
●
How can policy be associated with data to ensure policies survive
system boundaries?
– users can’t determine whether a site is in compliance with its policy
because many operations are hidden from view.

55. Before making an ACL
●
The most important step take before making an
access control list of a firewall is to first examine
the site's policy before making a ruleset.
●
The general rule of thumb is to keep your rules to
less than 20.
●
The more the fine grained control required the
longer the rule sets shall be.

56. Documenting ACLs
●
Try to group ACLs into logical areas. Much like
the idea of procedures which was created to avoid
the problems of spaghetti code in the 1960s and
1970s.
●
Document the relationship between the policy
and the Ruleset.

57. TCP Port 80
●
SOAP, HTTP, and a lot of other things use port
80. Even spywares use it.
●
The current status is that you should not block
this.
●
You can use deep packet analysis to find
spywares and http tunnels.
●
Company policy should clearly state what shall
happen to a person found using tunnels.

58. What was covered.
●
A brief idea of some of the things which need to
be taken into account in developing a security
policy were mentioned.
●
We hope you were able to glean at least the
basics as to why unwritten agreements need to be
converted into formal policies.

59. A lot more....
●
There are thousands of other things which need to
be catered for in depth in the process of
developing a comprehensive Security Policy.
●
For further questions please email or call any
time
●
ATRC.NET.PK
●
92­333­2486216, 92­21­38180991