Certification and Accreditation CS Unit 2:ITSEC System Classes LTC Tim O’Hara Ms Jocelyne Farah Mr Clinton Campbell

2 Unit Goals n Introduction n Goal: Determining System Class n ITSEC Classification Criteria n System Security Requirements References: DITSCAP Enclosure 7 – ITSEC System Class Description

3 What is a “system”? n Information System (a.k.a: Automated Information System, Information Technology System) –“Any equipment or interconnected system or subsystem of equipment that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission or reception of data and includes computer software, firmware, and hardware.”

4 Ultimate Goal n Fact: IT Systems perform valuable functions and processes in the government and in private sector n Goal: Missions must be completed and harm should be prevented IT Systems should be afforded an appropriate level of Confidentiality, Integrity, Availability and Accountability

5Definition n An ITSEC system class is a profile of system characteristics derived from considering how the same characteristics applied to the system's operation data affects community mission outcome.

6 Why System Classes? n Independent assessment is slow n Established and tested security requirements exist –Req. = F(Mission, Env., Arch.) –Deg compliance = F(value) n Benefit: Reuse –Issues –Risks –Requirements –Solutions –Implementations –Analyses Essentially, system classes provide an economical solution

7Benefits n Reuse past experience n Compare and contrast systems within a class or related tasks n Bound the security problem to satisfy individual class conditions n Consider systems security posture independently and in relation to other systems

8Limitations n Certification is faster, but not shorter n System engineering tradeoff decisions still necessary –Implementation of physical controls –Technical countermeasures

9 ITSEC Class Characteristics CharacteristicOperationDataInfrastructureSystemAlternatives Interfacing Mode Processing Mode Attribution Mode Mission- Reliance Factor Accessibility Factor Accuracy Factor Information Categories

10 Assigning Classes n Assignments based on similar risk –With respect to impact on other systems n Discriminating characteristics with respect to data and operations Don’t ignore the infrastructure where the system is connected

11 Interfacing Mode Goal: Containment of risk among connected systems n Operation, data, system risk to other connected operations, data, or systems Alternatives n Benign – No physical or logical relationships (closed community) n Passive – Limited to indirect interaction –Possibly physical relationships –Logical relationships tightly controlled n Active – Direct interaction –Physical and logical relationships

12 Processing Mode n Goal: Distinguish the way processing, transmission, storage, or data is handled –Reflect use of the system by one or more different sets of users or processes n Alternatives –dedicated level, compartmented level, system high level, and multi-level

13 Processing Mode Alternatives n Dedicated Level – Single information category –All users/processes have valid clearance for all data, and same need-to-know –Access controls equal for all users and processes n Compartmented Level – Different information categories with single-level access by individual users or processes at any "given time" –All users/processes have valid clearance for the most restricted data and need-to- know for particular data –Access controls are different for each user and process n System High Level – Actually multiple information categories, but treated as a single category –All users/processes have valid clearance for all data, but not the same need-to-know –Access controls equal for all users and processes n Multi-Level – Different information categories with simultaneous access by individual users/processes –All users/processes may not have the same clearance or need-to-know –Access controls are different for each user and process

14 Attribution Mode Goal n Degree or complexity of accountability required to establish authenticity and non-repudiation n Components –processing (p) –transmission (t) –Storage (s) –data (d) Alternatives n None – no p, t, s, & d can be attributed to users or processes n Rudimentary – only the most basic p, t, s, & d can be attributed n Selected – some p, t, s, & d can be attributed n Comprehensive – all (or most) p, t, s, & d can be attributed

15 Mission-Reliance Factor n Goal: Degree that mission success relies on operation, data, infrastructure, or the system –Independent of the criticality of the mission n Alternatives –None –Cursory –Partial –Total

16 Accessibility Factor n Goal: Degree that operation, data, infrastructure, or system needs to be available –From a security perspective, not performance n Alternatives –Reasonable –Soon –ASAP –Immediate

17 Accuracy Factor n Goal: Degree that integrity of operation, data, infrastructure, or system is needed –From a security perspective n Alternatives –Not-applicable – Integrity of data is irrelevant to operations –Approximate – Degree of integrity must be approximate to avoid operational impact –Exact – Degree of integrity must be exact or extremely high to avoid operational impact

18 Information Categories Goal n Categorize information based on common management principles and security requirements promulgated by security policy Alternatives n Unclassified n Sensitive n Privacy Act n Financially Sensitive n Proprietary Information n Administrative/Other n Collateral Classified n Compartmented and/or Special Access Classified

19 Remember the Initial Table? CharacteristicOperationDataInfrastructureSystemAlternatives Interfacing ModeBenign, Passive, or Active Processing Mode Dedicated Level, Compartmented Level, System High, or Multi-level Attribution ModeNone, Rudimentary, Basic, or Comprehensive Mission-Reliance Factor None, Cursory, Partial, or Total Accessibility Factor Reasonable, Soon, ASAP, or Immediate Accuracy FactorNot-applicable, Approximate, or Exact Information Categories Unclassified, Sensitive (Privacy Act, Financially Sensitive, Administrative, Proprietary, or Other), Collateral Classified, or Compartmented/Special Access Classified

20 Successful Implementation Secure Systems n Define security requirements early n Consider all ITSEC disciplines n Remember that system specific requirements can be inherited from mission and function –Some systems need higher level of assurance of implementation n But, how will security requirement sets be developed?

21 Initial Step n Analyze existing systems to determine classes –Accredited systems become “models” –Applicable ITSEC requirements, high-level architectures and approved solutions are stored in a common repository n Requirements definition process collects ITSEC requirements into a common database –Requirements are reviewed to remove conflicts and duplications –Result is a clean, and complete set of requirements –Requirements are allocated to each security class –Results are stored in a database

22 Recurring Steps n Construct a description of each system n Define the boundaries of the system compared to those that this system may interact Example Description n Mission of the system. n Functions this system will perform. n Interfaces with other systems. n Interactions across system interfaces. n Expected users of this system. n Information categories to be processed. n Time frame for developing and implementing the system. n Components of the system that will be automated versus manual. n Budget limitations that may affect the system. n Other system constraints or assumptions that will impact the system. If the systems aren’t understood well enough to create these descriptions, the DITSCAP is NOT ready to begin!

23 Determination of System Class n Select the applicable entries for the first three columns (operation, data, and infrastructure) n Resolve these entries to determine the most applicable value for the fourth column –The system should adequately support the needs as defined for operation, data, and infrastructure n Result: System with minimum security requirements specified in context of operation, data, and infrastructure. Don’t forget to update the common database if necessary!

03/14/ Questions