Sensitive Metric Collection and Reporting System

1. Sensitive Metric Collection and Reporting System Presentation for Critical Review Michael Aiello Hanning Gao Martin Goldberg Michael Sosonkin Jason Woloz

2. Agenda • System Overview • Primary Requirements Analysis • Preliminary Architecture • Security Trade Studies • Preliminary Assessment • System Design • Updated Risk Analysis • Updated Security Requirements • Security Design • Updated Security Assessment • Business Continuity Planning • Transmissions/Emissions Security • Physical Security

3. System Overview -Mission Needs • Procedural Need: • Currently, several ad-hoc processes collect metrics of varying sensitivities. • Currently, the oversight, organization, calculation, grouping and reporting on these metrics is accomplished through a tedious manual processes. • Compliance and Audit Need: • Operational risk reporting requirement

4. System Overview High Level Requirements • Repository • Handle metric storage and archival • Redundant off-site backup depository • Metric-collection Subsystem • Automated metric collection • Manual metric collection • Collection Job Configuration • Specified data point selection • Scheduled collection

5. System Overview High Level Requirements • Statistical Application • Task and execution manager • Result viewing • Automated monitoring and execution • Reporting • Centrally managed administrative interface • Multi-level third-party reporting capabilities

6. System Overview Conops-Description • Administrative collection job configuration is entered into the system • Specific collection configuration information is entered by the administrators (source authentication, collection frequency etc.) • Metric data is collected • The data collected is archived and organized (automatically) • Pluggable reporting and statistical packages interface with the system • Users then use these reporting tools to interface and perform analysis. • System may become a data source for other risk systems.

7. System Overview Conops-Data Flow

8. Primary Requirements Analysis Risk Analysis - Assets Assets • Firm Reputation – The metrics information, if used, can damage the company’s reputation. • Availability of metric repository- If system is unavailable for an extended period of time, it may not be able to effectively manage security risk. • Integrity of the computation results – The computation produces analysis of the security metrics. Results could indicate where and what the vulnerabilities are. • Contents of the metrics Database – The database contains information about the company’s vulnerabilities and information system setup. The information may be used to cause further damage. • Knowledge of firm vulnerabilities – This system provides a way of managing this, so if known then the company is exposed.

9. Primary Requirements Analysis Risk Analysis - Threats

10. Primary Requirements Analysis Risk Analysis - Threats

11. Asset Threat Combinations

12. Risk Approach

13. Primary Requirements Analysis Risk Analysis-Vulnerable and likelihood areas • Automated Collection Component • Statistical Modules • Reporting System • Configuration System • Metric Repository

14. Primary Requirements Analysis Policy • System Level • All communications must be secure between repository and its associated modules • Automated Collection Component • Will only connect to authorized information gathering agents • Statistical Packages • The statistical providers must not have write access to the database.

15. Primary Requirements Analysis Policy • Reporting System • Should only have read access to the repository • Configuration System • Only administrator authorized modules can be imported into the collection system. • Metric Repository • Metric database information should securely and redundantly in compliance with the mission critical information storage policy.

16. Primary Requirements Analysis Legal Requirements • The system in it’s most generic form does not suffer from compliancy issues • The system is meant as a way for companies to meet compliancy requirements • Due to its extensibility it can be deployed in a manner that would require it to meet a compliancy requirement

17. Primary Requirements Analysis Legal Requirements • SOX • Certifies the effectiveness of internal controls • Basel II • Monitors controls for operational risks • GLB • Controls for identified risks

18. Security Requirements Based on Risk Analysis, Global Policies Legal Requirements. • Encryption Requirements • Communications between data center and applications • Reporting Agents must be Authorized • Availability Requirements • Reporting Requirements • Auditors must easily be able to access system. They may wish to do this from an offsite location.

19. Preliminary Functional Architecture

20. Preliminary Security Architecture

21. Preliminary Security Architecture Justification • Confidentiality requirements elicited • Encrypted Channels • Integrity requirements elicited • Central repository and backup • Firewalls • Availability requirements elicited • Segregation of backend hardware • Repository Backup

22. Trade study -Product selection drivers • Functionality • Support Model • Time to deploy • Compliance with our security policies • Scalability

23. Trade study -Preliminary

24. Trade Study -Product Requirements Review • Vendor support • Vendor support is required for large components • Compliance with laws • Vendor must show how product is compliant • Compliance with standards • Interfaces must be standardized • Must be cheaper than building in house • Licensing • TCO • When deployed, cost of operation must be low

25. Trade study -Design

26. Security Matrix (selected items)

27. Newly Identified Vulnerable Areas • Automated Collection Component • Reception of manipulated information from in house developed systems- Medium • Reception of manipulated vendor feeds - Medium • Reception of manipulated emails with fraudulent metrics - High • Vulnerabilities in collecting software – Medium • Vulnerabilities on vendor interfaces- Low • Denial of Service attacks on collection system – Low

28. Identified Vulnerable Areas • Statistical Modules • Social engineering on the people that work at the company with this system – Low • External database interface vulnerabilities - High • Module database interfaces - Medium • Vulnerabilities in the software or hardware provided by a third party to analyze the data – Medium

29. Identified Vulnerable Areas • Reporting System • External interfaces (web reporting) - High • Forgery of reports - Low • Manipulation of communication between database and reporting subsystem - Low • Third party reporting software – Medium • Sniffing of report data - High

30. Identified Vulnerable Areas • Configuration System • Configuration integrity (administrators misconfigure) – High • User authentication credentials and storage – Medium • Metric Repository • Denial of service – High • Communication interfaces – High

31. Updated risk analysis • Highly vulnerable areas identified • Reception of manipulated emails with fraudulent metrics • External database interface vulnerabilities • Reporting interfaces (web reporting) • Configuration integrity • Denial of service • Communication interfaces

32. Updated risk analysis • Highest (Threat * Impact * Vulnerability) Combinations • Reporting interfaces (web reporting) • High impact (loss of CIA), • High vulnerability (may be exposed to non internal users) • Communication interfaces • High Impact, (loss of CIA) • High vulnerability (database may interact concurrently with several client applications) • Reception of manipulated emails with fraudulent metrics • Medium Impact (loss of integrity) • High vulnerability (difficult to verify source of email)

33. Updated Security Requirements • Email authentication support • Intrusion detection • Secure and segregated reporting Interfaces

34. Proposed Security Design

35. Updated Security Assessment • Additional hardware and design clarification meets new security requirements. • Additional items added to matrix

36. Business Continuity Plan Outline • 3 Major Areas • Unable to connect to data storage system • Use of local storage until the data storage system becomes available again. • If the data storage system becomes unavailable for an extended period, switch to redundancy data storage system. • Metric collection server is unavailable (configuration/reporting) • Equipment repaired by the manufacturer or by internal staff. Temporary server loaded with the back up and ran in the production environment. • Remote data sources become unreachable • Manager of local data source can maintain the storage of data for an extended period of time until the network outage is remedied. • Manager or an authorized individual can send the data through one of the other methods of data collection (i.e. manually enter data through a form or email the data)

37. TRANSEC/EMSEC • TRANSEC • Vulnerability • Traffic Analysis, Eavesdropping • Countermeasure • Wire placement, access control for data centers, encryption • EMSEC • Vulnerability • Electromagnetic radiation leak, observation, power signal • Countermeasure • Shielding, Zone of Control, Power filtering for highly critical systems in data centers • Solution • Partial implementation ( no network encryptor nor building shielding for non database aspects) • Most Risk of EMSEC is taken by data center (cheaper, keep all of the EMSEC sensitive equipment in one location)

38. Physical Security • Access Control • Access Authorization • Monitoring • Infrastructure • Power • Lighting • Secure Server Room • Equipment Protection • HVAC • Alarm • Security Guard • Standard data center security concerns. Risks transferred to Physical Security Group.

39. Conclusion Mission Need CONOPS Assets at Risk Threat Analysis Functional Rqmts Prelim. Risk Analysis Legal Rqmnts Primary Sec Rqmts System Arch. Assess Corp/Org Policy Security Arch Other Rqmts Derived Sec Rqmts System Design Risk Analysis Vulner. Analysis Assess Security Design