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

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 ThreatMotiveCapabilityAttack Likelihood Success Likelihood InsiderCareer advancement, steal money or information from company MediumHighMed CompetitorsObtain competitive edge by using inside information. HighMedHigh

10. Primary Requirements Analysis Risk Analysis - Threats ThreatMotiveCapabilityAttack Likelihood Success Likelihood Active Attacker find more vulnerabilities and steal information or money directly MediumHigh Script Kiddies Use computing resources for file trading or attacking other systems LowHighLow

11. Asset Threat Combinations AssetThreatPriorityJustification Firm Reputation Insider / Competition HighestEasiest target, highest value, hardest to define, must cover the bases against mal- intent insiders and competition Knowledge of organization's vulnerabilities Active Attacker HighActive attackers may use this information to further their attempt at compromising systems.

12. Risk Approach AssetThreatApproachJustification Firm Reputation Insider / Competition Mitigate / Accept Impossible to function without accepting some risk to firms reputation. Unknown avenues for reputational exposures. Knowledge of organization's vulnerabilities Active Attacker MitigateTechnical avenues for information leakage can be monitored, secured and mitigated.

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

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

15. 4. Reporting System Should only have read access to the repository 5. Configuration System Only administrator authorized modules can be imported into the collection system. 6. Metric Repository Metric database information should securely and redundantly in compliance with the mission critical information storage policy. Primary Requirements Analysis 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 System Feature Product Cost (with support) Provider Repository DatabaseOracle Database Standard Edition 4,995 + 1,098.90Oracle Intermediate Collection DBs MySQL$595.00/Server/YearMySQL Backup connectionFreeS/WANAdministrator Time Packet switchingCisco Catalyst 2950$629.00Cisco Intrusion DetectionSnortAdministrator TimeCisco System Secure communication OpenSSLDeveloper TimeOpenssl AuthenticationSSL CertificateIn house Traffic controlIPTablesAdministrator Time

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 System Feature Product Cost (with support) Provider Repository DatabaseOracle Database Standard Edition 4,995 + 1,098.90Oracle Intermediate Collection DBs MySQL$595.00/Server/YearMySQL Backup connectionCheck Point Enterprise Pro$25,000CheckPoint Packet switchingCisco Catalyst 2950$629.00Cisco Intrusion DetectionCISCO 3725 SERIES$3156Cisco System Secure communication SSLBlackbox$1,245.00ELDOS AuthenticationSSL Certificate$4395VeriSign Traffic controlFireWall-1 SecureServer$600CheckPoint

26. Security Matrix (selected items) Security RequirementProcess/HardwareJustification Depository system will be distributed to provide fail over Database will be setup to run in a cluster environment To ensure metric data collection is not interrupted or backlogged. Encrypted communication between repository and subsystems Use industry standard encryption protocol such as SSL or VPN To protect metric data’s integrity and confidentiality The repository network is segmented from rest of corporate network Use firewall to restrict access to repository network To protect repository from unauthorized access and also to protect data confidentiality Communications between the offsite backup system and the primary system should be encrypted Use VPN to connect onsite and off site depository system To protect metric data’s integrity and confidentiality Direct access to the repository will be restricted to system administrators Enclose depository system in locked down physical area and issue access only to sys admins To protect repository from unauthorized access and also to protect data confidentiality

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 Security RequirementProcess/HardwareJustification An intrusion detection system shall monitor and report potential attacks on the backend system IDS systemHigh risk vulnerabilities may exist in web reporting. IDS system alerts administrators of attempted break ins. System should allow for the reception of signed email metric data input Authentication serverTo protect metric data’s integrity. Email spoofing is trivial.

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 System Arch. Primary Sec Rqmts Legal Rqmnts Assets at Risk Corp/Org Policy Security Arch Threat Analysis Vulner. Analysis System Design Security Design Derived Sec Rqmts Other Rqmts Prelim. Risk Analysis Functional Rqmts Risk Analysis Assess