Software Assurance for Business Systems Integrators

Size: px
Start display at page:

Download "Software Assurance for Business Systems Integrators"

Transcription

1 Software Assurance for Business Systems Integrators Dr. Sumeet Malhotra Global Director of Advanced Research & Standards Strategy, UNISYS Member of Architecture Board, OMG

2

3

4

5 Security Additions to CMMI and FAA-iCMM Goal 1 An infrastructure for safety and security is established and maintained. Ensure safety and security awareness, guidance, and competency. Establish and maintain a qualified work environment that meets safety and security needs. Ensure integrity of information by providing for its storage and protection and controlling access and distribution of information. Monitor, report, and analyze safety and security incidents and identify potential corrective actions. Plan and provide for continuity of activities with contingencies for threats and hazards to operations and the infrastructure. Goal 2 Safety and security risks are identified and managed. Identify risks and sources of risks attributable to vulnerabilities, security threats, and safety hazards. For each risk associated with safety or security, determine the causal factors, estimate the consequence and likelihood of an occurrence, and determine relative priority. For each risk associated with safety or security, determine, implement, and monitor the risk mitigation plan to achieve an acceptable level of risk. Goal 3 Safety and security requirements are satisfied. Identify and document applicable regulatory requirements, laws, standards, policies, and acceptable levels of safety and security. Establish and maintain safety and security requirements, including integrity levels, and design the product or service to meet them. Objectively verify and validate work products and delivered products and services to assure safety and security requirements have been achieved and fulfill intended use. Establish and maintain safety and security assurance arguments and supporting evidence throughout the life cycle. Goal 4 Activities and products are managed to achieve safety and security requirements and objectives. Establish and maintain independent reporting of safety and security status and issues. Establish and maintain a plan to achieve safety and security requirements and objectives. Select and manage products and suppliers using safety and security criteria. Measure, monitor, and review safety and security activities against plans, control products, take corrective action, and improve processes.

6 Vulnerability Removal Filters

7 Correctness by Construction methodology of Praxis High Integrity Systems Process for developing High Integrity Software The seven key principles of Correctness by Construction are 1.Expect requirements to change. 2.Know why you're testing. 3.Eliminate errors before testing. 4.Write software that is easy to verify. 5.Develop incrementally. 6.Human Intelligence is critical don t rely on automation alone. 7.The executable software is only part of the picture. It is of no use without user manuals, business processes, design documentation, well-commented source code, and test cases. These should be produced as an intrinsic part of the development, not added at the end.

8 Common Criteria (NIAP Labs) Section 1 = History, concepts and principles of Security Evaluation Section 2 consists of Templates for creating Protection Profiles (PP) and a Security Target (ST) document The Protection Profiles and the Security Target allow the following process for evaluation: - An organization that wants to acquire or develop a particular type of security product defines their security needs using a Protection Profile. The organization then has the PP evaluated, and publishes it. - A product developer takes this Protection Profile, writes a Security Target that is compliance with the PP, and has this Security Target evaluated. - The product developer then builds a TOE (or uses an existing one) and has this evaluated against the Security Target.

9 Common Criteria (cont) Section 3 includes various methods of assuring that a product is secure The included 7 pre-defined sets of assurance requirements called the Evaluation Assurance Levels (EALs) are: Evaluation assurance level 1 (EAL1) - functionally tested Evaluation assurance level 2 (EAL2) structurally tested Evaluation assurance level 3 (EAL3) - methodically tested and checked Evaluation assurance level 4 (EAL4) - methodically designed, tested, and reviewed Evaluation assurance level 5 (EAL5) semi-formally designed and tested Evaluation assurance level 6 (EAL6) semi-formally verified design and tested Evaluation assurance level 7 (EAL7) - formally verified design and tested

10 Artifacts used for Security Assurance within Agile Methods Requirements Guidelines Specification Analysis Reviews Design and Analysis Application of specific architectural approaches Use of secure design principles Formal validation Informal validation Internal review External review Implementation Informal requirements traceability Requirements testing Informal validation Formal validation Security testing Vulnerability and penetration testing Test depth analysis Security static analysis High-level programming languages and tools Adherence to implementation standards Use of version control and change tracking Change authorization Integration procedures Use of product generation tools Internal review External review Security evaluation

11 An Overview of OMG Model Driven Architecture An Architectural Style that recommends the use of Industry Standard Models (from different domains and perspectives), Metadata (in a standards based repository), Mappings (Patterns & Transformations), the relevant Middleware and Methodologies for allowing developers and users to productively design, build, integrate and manage applications throughout the software development lifecycle while separating technology & business concerns. Back to overview

12 MDA An eclectic integration of best practices in Modeling, Middleware, Metadata, Mapping and Software Architecture Model Driven (UML, MOF, CWM ) Platform Independent Models (PIM) Platform Specific Models (PSM) Mappings : PIM <==> PSM Applies across the software life cycle Key Benefits Ability to analyze for existence of vulnerabilities at all stages of Software Development via formal models Improved Productivity for Architects, Designers, Developers and Administrators Lower cost of Application Development and Management Enhanced Portability and Interoperability Business Models and Technologies evolve at own pace on platform(s) of choice

13 MS Software Factories & OMG MDA Guide based 3D-VE Vulnerability Analysis Business Strategy Model (Business Capability Model) PIM Class Model \ Object Model PSM Class Model \ Object Model Business Rules & Requirements Model Business Swimlanes or Activity Models Business Entity Interactions \ Data Flow Diagrams PIM Activity Diagram \ Seq Diagram \ Collaboration Diagram Software Architecture Patterns CONFIGURATOR for TYPE OF PIM to System Features Model PSM STEREOTYPING PSM Activity Diagram \ Seq Diagram \ Collaboration Diagram PSM Deployment Model Code Tests UI UIP (Application Blocks) Build Scripts COTS Configurators

14 Seamless Integration: Forward and Reverse Traceable Engineering Traceability Skeletal Generation Full Association Full Generation Full Association Higher the abstraction level of Models, higher is the Association based generation (generation by using existing libraries of blueprints) Models are represented by code pieces and the code pieces are represented by the Models at the lowest levels of abstraction SASTMs have isomorphic one-to-one corresponding modeled elements for the in memory AST representation of normal code compilers Generic Abstract Syntax Tree Metamodels GASTM for OO code SASTM for Java ver x. Higher Level CIMs and PIMs UNISYS 3D-VE GASTM for dbs (ERDs) SASTM for C# ver y. Specific Abstract Syntax Tree Metamodels Code COTS Configurators Tests Build Scripts UI TEXTUAL REPRESENTATIONS GASTM for SAP R3 SASTM for SAP R3

15 Software Assurance Ecosystem: Infrastructure with Tools Evidence Trends, progress, Risk analysis KPIs, Assessment, etc. UML Models Source Code Test Cases Evidence Generators Report Generators Model Generators Source Generators TestCase Generators KDM Metrics Extracted Asset Info Extracted Vulnerabilities Security Policy Violations Business Violations Conformance Analyzer Transform Rule Miner Rule Analyzer Architect Rule Analyzer KDM CWM IMM KDM KDM SBVR BPML System Spec Platform spec System Structure/ Security Policy Micro Rules Business Micro Rules Security Policy Micro Rules Business Micro Rules Security Policy Rules Business Rules Parser Extractor Extractor Extractor Extractor Extractor Software System Artifacts Software System Artifacts Hardware Platforms Hardware Environment Security/Business Security/Business Specifications Specifications

16 Vulnerabilities can be in anywhere - Business Models down to any Infrastructure Artifacts Business operations, Software and Infrastructure Operations are formally modelled in order to share and find vulnerabilities using a formal framework Traceability is the backbone for maintaining and managing the analysis of vulnerabilities at any abstraction level Strategic Goal Model, Measurement Model Process & Organization Models Information & Component Models Infrastructure & Topology Models If you can t model it you can t fully understand or predict behavior

17 Blueprints Artifact Traceability for Vulnerability Impact Assessment SL 1 A 1 A 2 A 3 A 4 A 5 A 6 SL 2 A 7 A 8 A 9 A 10 A 11 A 12 Blueprint Desktop Repository SL 3 A 13 A 14 A 15 A 16 A 17 A 18 Tools Standard Eclipse QVT SL 4 A 19 A 20 A 21 A 22 A 23 A 24 MDF IMS Exhaustively define at the repository level all possible traceability relationships between Blueprint Artifacts at the Repository Level Vulnerabilities can be deduced at all levels of abstraction

18 Real Time Enterprise for complete Vulnerability Assessment For Unisys, RTI is more than a set of technologies. It s integral to a framework that connects a model-based view of the business with IT and business process execution to create a closed loop that drives continuous business optimization Business Performance Management KPI thresholds Real-time process monitoring Process & IT event management Real Time Infrastructure Shared resources Business-driven resource allocation Automated servicelevel optimization Business Models Strategy and process models Industry-specific blueprints Process simulation Technical Models Application and infrastructure models Process IT Service correlation IT service governance RTI becomes much more powerful when combined with BPM to drive the Real Time Enterprise an organization that anticipates and capitalizes on business opportunities and threats before they happen

19 3D-VE Artifacts Allow Scenario, Simulation and Impact Analysis for vulnerability assessment Impact analysis and scenario planning allows clients to rapidly build ROI models for multiple scenarios using process simulation and cost estimating capabilities of the 3D-VE toolsets Agile Change Management allows rapid changes to business process and assessment of financial impacts of change

20 Accurate Measurement Operations should be designed to meet Key Performance Indicators (KPIs). KPIs are derived from information in many levels of an operating enterprise Blueprints aligns these metrics. Management Business Process Applications Infrastructure Profit Efficiency Cost Efficiency Risk Performance Transaction Efficiency / Effectiveness Capacity Throughput Customer Product Geographic SLA levels Cycle Time Utilization Activity Based Costing Avg transaction value Avg transaction volume Inventory CPU cycles Messages per sec/min/day You cannot improve what you cannot measure!

21 3D-VE Foundation For Secure Business Vulnerability Analysis Content at different abstraction levels VERTICAL INDUSTRY SOLUTIONS UNISYS BUSINESS BLUEPRINTS TECHNOLOGY ELEMENTS TECHNOLOGY ROADMAP FOUNDATION

22 References ISO/IEC for System Life Cycle Processes, available from ISO/IEC for Software Life Cycle Processes, available from ISO/IEC for System and Software Integrity Levels, available from Cleanroom Software Engineering [Linger 94, Mills 87] US-CERT BUILD SECURITY IN:

23 References Agile Alliance. Manifesto for Agile Software Development (2005). Beznosov, Konstantin. Extreme Security Engineering: On Employing XP Practices to Achieve Good Enough Security without Defining It. First ACM Workshop on Business Driven Security Engineering (BizSec). Fairfax, VA, Oct. 31, Beznosov, Konstantin & Kruchten,, Phillipe. Towards Agile Security Assurance, Proceedings of the 2004 Workshop on New Security Paradigms. White Point Beach Resort, Nova Scotia, Canada, September 20-23, New York, NY: Association for Computing Machinery, The Common Criteria Portal (2005). University of Wisconsin Madison. Fuzz Testing of Application Reliability (2006). Goldenson, D. & Gibson, D. Demonstrating the Impact and Benefits of CMMI: An Update and Preliminary Results (CMU/SEI-2003-SR-009, ADA418491). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, Hall, Anthony & Chapman, Roderick. Correctness by Construction: Developing a Commercial Secure System. IEEE Software 19, 1 (Jan./Feb. 2002): Herbsleb, J.; Carleton, A.; Rozum, J.; Siegel, J.; & Zubrow, D. Benefits of CMM-Based Software Process Improvement: Initial Results (CMU/SEI-94-TR-013, ADA283848). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, IEEE Standards Coordinating Committee. IEEE Standard Glossary of Software Engineering Terminology (IEEE Std ). Los Alamitos, CA: IEEE Computer Society, 1990 (ISBN ). Kitson, David H. "A Tailoring of the CMM for the Trusted Software Domain." Proceedings of the Seventh Annual Software Technology Conference. Salt Lake City, Utah, April 9-14, Linger, R. C. Cleanroom Process Model. IEEE Software 11, 2 (March 1994): Lipner, Steve & Howard, Michael. The Trustworthy Computing Security Development Lifecycle (2005). Michael, C. C. & Radosevich, Will. Black Box Security Testing Tools (2005). Microsoft. Microsoft Security Advisories (2006). Mills, H.; Dyer, M.; & Linger, R. C. Cleanroom Software Engineering. IEEE Software 4, 5 (September 1987): The MITRE Corporation. Common Vulnerabilities and Exposures.[NASA]NASA Software Assurance Technology Center. Software Assurance Guidebook, NASA-GB-A201. Paulk, M.; Curtis, B.; Chrissis, M.; & Weber, C. Capability Maturity Model for Software (Version 1.1) (CMU/SEI-93-TR-024, ADA263403). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, Poppendieck, M. & Morsicato, R. Using XP for Safety-Critical Software. Cutter IT Journal 15, 9 (2002): Redwine, S. T. & Davis, N., eds. Processes to Produce Secure Software. Improving Security Across the Software Development Lifecycle (National Cybersecurity Partnership Taskforce Report), Appendix B. (2004). Ross, Philip E. The Exterminators: A Small British Firm Shows That Software Bugs Aren t Inevitable. IEEE Spectrum 42, 9 (September 2005): The SANS Institute. The Twenty Most Critical Internet Security Vulnerabilities (Updated) The Experts Consensus (2005). Software Engineering Institute. Maturity Profile. (2005). Unites States Computer Emergency Readiness Team. Technical Cyber Security Alerts (2005). Wäyrynen, J.; Bodén, M.; & Boström, G. Security Engineering and extreme Programming: an Impossible Marriage? Extreme Programming and Agile Methods - XP/Agile Universe 2004: 4th Conference on Extreme Programming and Agile Methods. Calgary, Canada, August 15-18, Berlin, Germany: Springer-Verlag, 2004 (ISBN X).

24 What We Do. How We Do It. 3D Blueprinting What We Deliver.