Barbed Wire Network Security Policy 27 June 2005 7

1,239 views

Published on

How to develop a security policy

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,239
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
24
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Barbed Wire Network Security Policy 27 June 2005 7

  1. 1. How to develop a Security Policy By : Khawar Nehal Seminar on Network Security Sponsored by BarbedWire 27 June 2005
  2. 2. Topics Covered ● What is a security Policy ● Unenforceable Policies ● Email and web filtering  ● Approaches to Policy Development ● ACL management based on Policies
  3. 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. 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. 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. 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. 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. 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. 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. 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. 11. Examples ● Fragmented packets do not have port numbers in  their headers. ● A simple firewall cannot decide wether to accept  or reject.
  12. 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. 13. Examples ● If outbound ICMP unreachables are  disabled  then let the fragment through. ● Drop the packet and make the sender retransmit.
  14. 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. 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. 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. 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. 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. 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. 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. 21. Content Filtering ● Client Side content filters have matured but  require a subscription. ● Proxy server based content filters are a better  solution according.
  22. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 37. Many approaches ● There are many approaches to developing  policies. ● The recommended method these days is a risk  based approach.
  38. 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. 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. 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. 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. 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. 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. 44. Written copy. ● Do not present as a discussion only. ● Provide a written copy to everyone involved in  the process.
  45. 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. 46. The Problem ● Software systems fail to  adequately address security  and privacy issues during  analysis & design. 
  47. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×