1 / 39

Sensitive Metric Collection and Reporting System

Sensitive Metric Collection and Reporting System. Presentation for Critical Review. Michael Aiello Hanning Gao Martin Goldberg Michael Sosonkin Jason Woloz. Agenda. System Overview Primary Requirements Analysis Preliminary Architecture Security Trade Studies Preliminary Assessment

thuy
Download Presentation

Sensitive Metric Collection and Reporting System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related