Chapter 8: Communications and Operations Management

1. Chapter 8: Communications and Operations Management

2. Objectives • Author useful standard operating procedures • Implement change control processes • Develop an incident response program • Protect against malware • Advocate for formal backup & restore procedures • Manage portable storage devices

3. Objectives Cont. • Secure the transport, reuse & disposal of media • Protect the integrity of information published on publicly-available systems • Recognize the unique security requirements of email and email systems • Write policies and procedures to support operational security

4. Standard Operating Procedures • SOPs provide directions to improve communication, reduce training time, and improve work consistency • SOPs should be documented to protect the company from the pitfalls of institutional knowledge • If a business process is only known by one employee, and that employee becomes unavailable, how is this process going to be performed successfully?

5. Standard Operating Procedures Cont. • SOPs should be written in as simple a style as possible for all to clearly understand the procedures • SOPs should include all steps of a given procedure • SOPs should not be overly detailed and should remain clear

6. Standard Operating Procedures Cont. • If a procedure contains less than 10 steps, it should be presented in step format • If a procedure contains 10 steps or more, but few decisions, it should be presented in a graphical format or a hierarchical format • If a procedure requires many decisions, then it should be presented as a flowchart

7. Standard Operating Procedures Cont. • Once a procedures has been researched, documented, reviewed and tested, it should be authorized by the information system owner • The integrity of the SOP documents must be protected so that employees don’t get to follow instructions that have been maliciously tampered with

8. Standard Operating Procedures Cont. • The change management process must be defined so that the SOPs mirror the evolution of the business processes • All revisions of the SOP documents must be reviewed and approved by the information system owner

9. Operational Change Control • Change control: internal procedure by which only authorized changes are made to software, hardware, network access privileges or business processes • Change control process • Analysis of the need • What is the current situation? • What is the goal of the change? • What is the impact of the change?

10. Operational Change Control Cont. • Change control process (cont.): • Formal request for change • Who is authorized to make the request? • To whom should the request be made? • Who should approve the change? • Review of the request by the information owner • What are the reasons prompting the request for change? • Specifically, what changes are requested? • Authorization

11. Operational Change Control Cont. • Change Control Authorization • Once authorized, the actual change process must be monitored and documented, whether successful or not. This documentation should include the following: • Who requested the change? • Who approved the change? • What specific changes were made? • Was the change successful? • If not, was the system recovered?

12. Operational Change Control Cont. • Version control is important for all policy and procedure documents, to ensure that all employees are relying upon the latest information uniformly across the organization

13. Incident Response Program • The right time to develop an Incident Response program is before an incident actually occurs • Risk-free, therefore incident-free, environments do not exist • Risk management is the formal process according to which risk is identified, assessed and mitigated by implementing one or more controls

14. Incident Response Program Cont. • Incidents can be caused to malicious actions or simple errors/accidents • An incident response plan is a roadmap of reporting, responding and recovery actions • Incident response procedures are step-by-step implementations to come back to normal • An incident response plan coupled with incident response procedures form an incident response program

15. Incident Response Program Cont. • Incident Classification • Just as the origin of incidents varies, so does their severity levels • All foreseeable incidents should be identified, reviewed and assigned a severity level • Severity levels should be assigned by executive management and organized in tiers • Different identified severity levels may have different handlers

16. Incident Response Program Cont. • Incident Handler • A designated incident handler (IH) is one or more people responsible for: • Responding to a specific incident • Investigating a specific incident • Overseeing recovery efforts • Documenting the resolution

17. Incident Response Program Cont. • The IH is responsible for responding to a specific incident • Within the designated timeframe • By assembling the right team of individuals to resolve the issue • Managing problem resolution

18. Incident Response Program Cont. • The IH is responsible for investigating a specific incident • Identifying and assessing the evidence • Maintaining the chain of evidence • Protecting access to the evidence

19. Incident Response Program Cont. • The IH is responsible for overseeing the recovery efforts • Identifying the employee(s) with the relevant skills • Managing the team

20. Incident Response Program Cont. • The IH is responsible for documenting the resolution of that incident • All steps taken to deal with the incident should be documented • A final report should be created based on that documentation • The final report should be analyzed and reviewed • Analysis and review may bring new information and ideas on how to deal with similar incidents

21. Incident Severity Level • Classifying Incidents by Severity Levels • Tier 1: • Most serious • Considered a major incident • Requires immediate response • Could have long-term implications for the company • Example: Any violation of the Law

22. Incident Severity Level Cont. • Tier 2: • Serious • Considered a major incident • Requires response within 2 to 4 hours of detection • Defined as • Incursion on non-critical systems or information • Detection of precursor to a focused attack • Believed threat of imminent attack • Example: Compromise of a user password

23. Incident Severity Level Cont. • Tier 3: • Less severe • Should be handled within one working day • Defined as a problem that can: • Be resolved by system user or operator • Should not involve any damage to the system or company data • Example: Excessive bandwidth use

24. Incident Severity Level Cont. • Tier 4: • Proactive high priority • Requires response within 3 business days • Defined as: • Threat of future attack • Detection of reconnaissance (exploration) • Example: Potential exploit

25. Incident Severity Level Cont. • Tier 5: • Proactive low priority • Unspecified response time required • Defined as: • Unsubstantiated rumor or security incident

26. Incident Reporting, Response, and Handling Procedures • Goal: make procedures easy so that all employees can use them • The employee who discovers an incident may not be trained or an IT technician! • Procedures mean consistency & accuracy in the way incidents are reported • Any discovered incident should be reported immediately • The culture of the company needs to incorporate this point so that employees don’t feel like they may be ridiculed if they are wrong

27. Incident Reporting, Response, and Handling Procedures Cont. • Incident Response Procedures • Who is responsible to handle an incident? • Who is the designated incident handler? • Within what timeframe should the response come? • Should external resources be used? • Law enforcement • 3rd-party contractors • Compliance experts • Forensic experts • Legal counsel

28. Incident Reporting, Response, and Handling Procedures Cont. • Incident Handling Procedures • Focus on: • Containment • Limit the scope and magnitude of the incident • Eradication • Problem eliminated • Vulnerabilities identified and addressed • Recovery • Return to full operational status

29. Incident Reporting, Response, and Handling Procedures Cont. • Incident Handling Procedures • Different handling procedures should be created for perceived types of incidents • It is impossible to have procedures for ALL incident types • The nature of the incident will dictate differences in containment, eradication and recovery procedures

30. Incident Reporting, Response, and Handling Procedures Cont. • Analyzing Incidents & Malfunctions • Goal: after an incident has been resolved, what can be learned about the incident / malfunction so that it does not happen again? • Goal: while the incident is still vivid in employees’ memory, an analysis of the actual resolution process will yield accurate details and results

31. Incident Reporting, Response, and Handling Procedures Cont. • Reporting Suspected or Observed Security Weaknesses • Employees MUST report all perceived or real security weaknesses • Failure to do so WILL be viewed as a malicious act • Employees, through daily use of information systems, can come in contact with weaknesses unknown to the developers

32. Incident Reporting, Response, and Handling Procedures Cont. • Testing Suspected or Observed Security Weaknesses • Employees MUST NOT test suspected or observed security weaknesses: their responsibility is to REPORT those weaknesses immediately • Conducting unauthorized testing of vulnerabilities is viewed as a malicious act

33. Malicious Software Also known as Malware. Types of malware include: • Virus: a piece of malicious code that needs a host file to replicate • Worm: a piece of malicious code that does not need a host file, and targets a known vulnerability • Spyware: malicious code installed on a user’s machine unbeknownst to them, which monitors their activity. Spyware virulence levels vary based on which spyware is installed

34. Malicious Software Cont. • Trojan Horse: potentially destructive, malicious code that masquerades as a legitimate & benign application. Most Trojans are of the RAT variety – Remote Access Trojan – which allow an unauthorized user to gain admin-level access to the infected system. • Key Logger: application that runs discreetly on a computer and records all keystrokes into a text file

35. Malicious Software Cont. • Logic Bomb: malicious code that is loaded but lies dormant until a certain pre-determined condition is met.

36. Malware Controls • Users should not be able/allowed to install software to their company-owned machines • Antivirus solutions should be installed on all computers in the organization • AV software must be updated every day • Different solutions from different vendors should be deployed • Two parts: • The engine • The definition files

37. Malware Controls Cont. • Regular port scans should be run on servers and workstations, as some malicious code will open specific, known ports. Port scans can help detect an infected machine • A port is to a computer address what an extension is to a phone number. One phone number may have different extensions that allow the caller to communicate with different people/departments. A computer may have a single address, but many ports, that allow another computer to interact with different services on that PC

38. Malware Controls Cont. • Security awareness is gained through training. All employees should be trained and understand: • What malware is • Why it is important to update the antivirus solution • How a machine can get infected • The responsibility to alert IT of any suspected machine infection

39. Information System Backup • Why back up data? • Company may be mandated to do so • Failure to back up threatens data availability and data integrity • Lost/corrupt data can also have a negative impact on the company: • Financially • Legally • PR-wise

40. Defining a Backup Strategy • The following aspects should be considered when the strategy is designed: • Reliability • Speed • Simplicity • Ease of use • Security of the stored information

41. Defining a Backup Strategy Cont. • The grandfather-father-son strategy: • Based on a 3-week rotation • Separate tapes for daily, weekly, monthly & quarterly backups • Requires: • 4 daily tapes (labeled Monday-Thursday) • 5 weekly tapes (labeled Week1-Week5) • 3 monthly tapes (labeled Month A-C)

42. The Importance of Test Restores • If the company relies on backup to protect data integrity & availability, then it needs to be sure that the information stored on the backup media is restorable in case of an incident • Just as it is important that backup would take place according to a set schedule, test restores should also be officially scheduled

43. The Importance of Test Restores Cont. • The test restore strategy should be: • Tested • Documented • Officially approved • Once approved, an updated copy of the test restore strategy should be stored with the backup tapes at the remote location

44. Managing Portable Storage • Portable Storage Devices • Portable Storage Devices (PSDs) are transportable drives or disks that can be moved easily from one computer to another • Also known as removable media • Includes: • Recordable CD ROMs & DVDs • USB “thumbdrives” • USB & FireWire hard drives • MP3 players

45. Managing Portable Storage Cont. • Risks: data confidentiality is threatened by PSD’s because: • They can be easily lost – along with the data they contain • An MP3 player looks like an MP3 player – not like the 20GB hard drive w/ a USB connector that it is • Thumbdrives are cheap, small & easy to conceal, yet offer big storage room • USB drives are small, and install automatically on most operating systems

46. Managing Portable Storage Cont. • Reality: not all PSDs are bad, and some can have a legitimate use in the company • This impacts the way the policy that manages the use of PSDs must be written. It cannot simply deny the use of all PSDs

47. Managing Portable Storage Cont. • Controlling non-company-owned removable media is a growing concern • There is no true “network perimeter” anymore • Reminder: most hacking attacks originate from inside the network • The policy should clearly indicate what non-company-owned items are not allowed on company premises, such as MP3 players, phones w/ a digital camera and PDAs

48. Managing Portable Storage Cont. • Controlling company-owned removable media that leaves the company is also a growing concern • The policy should recognize the risk of loss of confidentiality of data, along with the financial, legal, and PR ramification associated with the loss/theft of a PSD • A formal risk assessment should be conducted

49. Managing Portable Storage Cont. • A policy should answer the following questions: • Who is allowed to leave the company premises with a PSD? • What data should never be placed on a PSD? • What is the approved procedure to protect data stored on a PSD? • Encryption types • What is the procedure to report the loss/theft of a company-owned PSD?

50. Storing Removable Media • Any media, removable or not, that contains sensitive information should be stored securely. It is especially more important with removable media because of its portability, which usually means a small form factor that makes the device easy to conceal – and therefore steal • This media may include CD ROMs, DVDs, backup tapes and various disks such as floppies and Zips