Chapter 16 Physical and Infrastructure Security Physical and Infrastructure Security Logical security •Protects computer-based data from software-based and communicationbased threats Physical security •Also called infrastructure security •Protects the information systems that contain data and the people who use, operate, and maintain the systems •Must prevent any type of physical access or intrusion that can compromise logical security Premises security •Also known as corporate or facilities security •Protects the people and property within an entire area, facility, or building(s), and is usually required by laws, regulations, and fiduciary obligations •Provides perimeter security, access control, smoke and fire detection, fire suppression, some environmental protection, and usually surveillance systems, alarms, and guards Physical Security Overview • Protect physical assets that support the storage and processing of information Involves two complementary requirements: Prevent damage to physical infrastructure Concerns include information system hardware, physical facility, support facilities, and personnel Prevent physical infrastructure misuse that leads to the misuse or damage of protected information Includes vandalism, theft of equipment, theft by copying, theft of services, and unauthorized entry Physical Security Threats Physical situations and occurrences that threaten information systems: •Environmental threats •Technical threats •Human-caused threats Source: ComputerSite Engineering, Inc. Component or Medium Flexible disks, magnetic tapes, etc. Optical media Hard disk media Computer equipment Thermoplastic insulation on wires carrying hazardous voltage Paper products Sustained Ambient Temperature at which Damage May Begin 38 ºC (100 ºF) 49 ºC (120 ºF) 66 ºC (150 ºF) 79 ºC (175 ºF) 125 ºC (257 ºF) 177 ºC (350 ºF) Source: Data taken from National Fire Protection Association. 1300 2300 2200 1200 2100 2000 1900 1000 1800 1700 900 1600 1500 800 1400 1300 700 Fire Temperature, ºF Fire Temperature, ºC 1100 1200 600 1100 1000 500 900 800 400 1 2 3 4 5 6 7 8 Duration, hours Figure 16.1 Standard Fire Temperature-Time Relations Used for Testing of Building Elements Temperature 260 Cº/ 500 ºF 326 Cº/ 618 ºF 415 Cº/ 770 ºF 480 Cº/ 896 ºF Effect Wood ignites Lead melts Zinc melts An uninsulated steel file tends to buckle and expose its contents Temperature 625 Cº/ 1157 ºF Effect Aluminum melts 1220 Cº/ 2228 ºF 1410 Cº/ 2570 ºF Cast iron melts Hard steel melts Water Damage Primary danger is an electrical short A pipe may burst from a fault in the line or from freezing Floodwater leaving a muddy residue and suspended material in the water Sprinkler systems set off accidentally Due diligence should be performed to ensure that water from as far as two floors above will not create a hazard Chemical, Radiological, and Biological Hazards • Pose a threat from intentional attack and from accidental discharge • Discharges can be introduced through the ventilation system or open windows, and in the case of radiation, through perimeter walls • Flooding can also introduce biological or chemical contaminants Dust and Infestation Dust • Often overlooked • Rotating storage media and computer fans are the most vulnerable to damage • Can also block ventilation • Influxes can result from a number of things: o Controlled explosion of a nearby building o Windstorm carrying debris o Construction or maintenance work in the building Infestation • Covers a broad range of living organisms: o High-humidity conditions can cause mold and mildew o Insects, particularly those that attack wood and paper Technical Threats • Electrical power is essential to run equipment o Power utility problems: • Under-voltage - dips/brownouts/outages, interrupts service • Over-voltage - surges/faults/lightening, can destroy chips • Noise - on power lines, may interfere with device operation Electromagnetic interference (EMI) • Noise along a power supply line, motors, fans, heavy equipment, other computers, cell phones, microwave relay antennas, nearby radio stations • Noise can be transmitted through space as well as through power lines • Can cause intermittent problems with computers Human-Caused Threats • Less predictable, designed to overcome prevention measures, harder to deal with • Include: o Unauthorized physical access • Information assets are generally located in restricted areas • Can lead to other threats such as theft, vandalism or misuse o Theft of equipment/data • Eavesdropping and wiretapping fall into this category • Insider or an outsider who has gained unauthorized access o Vandalism of equipment/data o Misuse of resources Physical Security Prevention and Mitigation Measures • One prevention measure is the use of cloud computing • Inappropriate temperature and humidity o Environmental control equipment, power supply • Fire and smoke o Alarms, preventative measures, fire mitigation o Smoke detectors, no smoking • Water o Manage lines, equipment location, cutoff sensors • Other threats o Appropriate technical counter-measures, limit dust entry, pest control Uninterruptible power supply (UPS) for each piece of critical equipment Critical equipment should be connected to an emergency power source (like a generator) To deal with electromagnetic interference (EMI) a combination of filters and shielding can be used Mitigation Measures Technical Threats Physical access control • Restrict building access • Controlled areas patrolled or guarded • Locks or screening measures at entry points • Equip movable resources with a tracking device • Power switch controlled by a security device • Intruder sensors and alarms • Surveillance systems that provide recording and real-time remote viewing Physical equipment damage recovery •Depends on nature of damage and cleanup Most essential element of recovery is redundancy •Provides for recovery from loss of data •Ideally all important data should be available off-site and updated as often as feasible •Can use batch encrypted remote backup •For critical situations a remote hotsite that is ready to take over operation instantly can be created •May need disaster recovery specialists Physical and Logical Security Integration • Numerous detection and prevention devices • More effective if there is a central control • Integrate automated physical and logical security functions o o o o Use a single ID card Single-step card enrollment and termination Central ID-management system Unified event monitoring and correlation • Need standards in this area o FIPS 201-1 “Personal Identity Verification (PIV) of Federal Employees and Contractors” PIV Card Issuance and Management Access Control PKI directory & certificate status responder Authorization data Physical Access Control Key management Card issuance & maintenance Identity profiling & registration I&A Physical resource Authorization Logical Access Control I&A Logical resource Authorization Authorization data Card reader /writer I&A = Identification and Authentication LEGEND Shapes Direction of information flow PIV card Processes PIN input device Components Biometric reader PIV Front end Figure 16.2 FIPS 201 PIV System Model Shading PIV system subsystem Related subsystem Contactless smartcard reader Smartcard reader Physical access control system (PACS) server Optional biometric reader Vending, e-purse and other applications Certificate authority PIV system card enrollment station Smartcard and biometric middleware Access control system Camera Optional biometric reader Smartcard reader Card printer Smartcard programmer Optional biometric reader Active directory Other user directories Figure 16.3 Convergence Example Human resources database Unrestricted Controlled Limited Exclusion CAK+BIO–A PKI C BIO B CHUID+VIS CAK A (a) Access Control Model CONTROLLED AREA Fenced-in area containing a number of buildings LIMITED AREA EXCLUSION AREA C B Building housing lab space and other sensitive areas Room housing trade secrets Facility services HQ Admin Buildings A Visitor Registration (b) Example Use Figure 16.4 Use of Authentication Mechanisms for Physical Access Control Trusted Computing and Multilevel Security Computer Security Models Two fundamental computer security facts: All complex software systems have eventually revealed flaws or bugs that need to be fixed It is extraordinarily difficult to build computer hardware/software not vulnerable to security attacks Mythical Man Month The Mythical Man-Month: Essays on Software Engineering is a book on software engineering and project management by Fred Brooks, whose central theme is that "adding manpower to a late software project makes it later". This idea is known as Brooks' law. Brooks discusses several causes of scheduling failures. The most enduring is his discussion of Brooks's law: Adding manpower to a late software project makes it later. Manmonth is a hypothetical unit of work representing the work done by one person in one month; Brooks's law says that the possibility of measuring useful work in man-months is a myth, and is hence the centerpiece of the book. Complex programming projects cannot be perfectly partitioned into discrete tasks that can be worked on without communication between the workers and without establishing a set of complex interrelationships between tasks and the workers performing them. Mythical Man Month Therefore, assigning more programmers to a project running behind schedule will make it even later. This is because the time required for the new programmers to learn about the project and the increased communication overhead will consume an ever increasing quantity of the calendar time available. When n people have to communicate among themselves, as n increases, their output decreases and when it becomes negative the project is delayed further with every person added. Group intercommunication formula: n(n − 1) / 2 Example: 50 developers give 50 · (50 – 1) / 2 = 1225 channels of communication Table 13.1 Terminolog y Related to Trust Audit file Subjects Reference Monitor (policy) Security kernel database Subject: security clearance Object: security classification Figure 13.7 Reference Monitor Concept Objects Bob Bob: RW Reference Monitor Bob Bob: RW "CPE170KS" Program "CPE170KS" Program Data file Alice: RW Bob: W Alice Program Alice: RW Bob: W Alice Back-pocket file Back-pocket file Program (a) Bob Data file (c) Bob: RW Reference Monitor Bob Bob: RW "CPE170KS" Program "CPE170KS" Program Data file Alice: RW Bob: W Alice Program Back-pocket file (b) Data file Alice: RW Bob: W Alice Back-pocket file Program (d) Figure 13.8 Trojan Horse and Secure Operating System Multilevel Security (MLS) RFC 4949 defines multilevel security as follows: “A mode of system operation wherein (a) two or more security levels of information are allowed to be handled concurrently within the same system when some users having access to the system have neither a security clearance nor need-to-know for some of the data handled by the system and (b) separation of the users and the classified material on the basis, respectively, of clearance and classification level are dependent on operating system control.” Department Table - U Employee - R Did Name Mgr Name Did Salary Eid 4 accts Cathy Andy 4 43K 2345 8 PR James Calvin 4 35K 5088 Cathy 4 48K 7712 James 8 55K 9664 Ziggy 8 67K 3054 (a) Classified by table Department Table Employee Did -U Name -U Mgr -R Name -U Did -U Salary -R Eid -U 4 accts Cathy Andy 4 43K 2345 8 PR James Calvin 4 35K 5088 Cathy 4 48K 7712 James 8 55K 9664 Ziggy 8 67K 3054 (b) Classified by column (attribute) Figure13.10 13.9 Approaches to Database Classification (page 1 of 2) Figure Department Table Did Name Mgr 4 accts Cathy 8 PR James Employee Name Did Salary Eid R Andy 4 43K 2345 U U Calvin 4 35K 5088 U Cathy 4 48K 7712 U James 8 55K 9664 R Ziggy 8 67K 3054 R (c) Classified by row (tuple) Department Table Did 4-U 8-U Name Mgr accts - U Cathy - R PR - U James -R Employee Name Did Salary Eid Andy - U 4-U 43K - U 2345 - U Calvin - U 4-U 35K - U 5088 - U Cathy - U 4-U 48K - U 7712 - U James - U 8-U 55K - R 9664 - U Ziggy - U 8-U 67K - R 3054 - U (d) Classified by element Figure Figure13.10 13.9 Approaches to Database Classification (page 2 of 2) Database Security Read Access • • • DBMS enforces simple security rule (no read up) Easy if granularity is entire database or at table level Inference problems if have column granularity o If can query on restricted data can infer its existence • SELECT Ename FROM Employee WHERE Salary > 50K o Solution is to check access to all query data • Also have problems if have row granularity o Null response indicates restricted/empty result • No extra concerns if have element granularity Database Security Write Access • • Enforce *-security rule (no write down) Have problem if a low clearance user wants to insert a row with a primary key that already exists in a higher level row: o Can reject, but user knows row exists o Can replace, compromises data integrity o Polyinstantiation and insert multiple rows with same key, creates conflicting entries • • Same alternatives occur on update Avoid problem if use database/table granularity • Concept from Trusted Computing Group • Hardware module at heart of hardware/software approach to trusted computing (TC) • Uses a TPM chip o Motherboard, smart card, processor o Working with approved hardware/software o Generating and using crypto keys Has 3 basic services: • Authenticated boot • Certification • Encryption Authenticated Boot Service • Responsible for booting entire OS in stages and ensuring each is valid and approved for use o At each stage digital signature associated with code is verified o TPM keeps a tamper-evident log of the loading process • Log records versions of all code running o Can then expand trust boundary to include additional hardware and application and utility software o Confirms component is on the approved list, is digitally signed, and that serial number hasn’t been revoked. • Result is a configuration that is well-defined with approved components Certification Service • Once a configuration is achieved and logged the TPM can certify configuration to others o Can produce a digital certificate • Confidence that configuration is unaltered because: o TPM is considered trustworthy o Only the TPM possesses this TPM’s private key • • Include challenge value in certificate to also ensure it is timely Provides a hierarchical certification approach o Hardware/OS configuration o OS certifies application programs o User has confidence in application configuration Encryption Service • • • Encrypts data so that it can only be decrypted by a machine with a certain configuration TPM maintains a master secret key unique to machine o Used to generate secret encryption key for every possible configuration of that machine Can extend scheme upward o Provide encryption key to application so that decryption can only be done by desired version of application running on desired version of the desired OS o Encrypted data can be stored locally or transmitted to a peer application on a remote machine • • • • • • • • • • • Chip on motherboard – not user removable First laptops were IBM thinkpads & enterprise only Completely open – over 100 companies, GPL’d TPM enhanced BIOS Secure path between the keyboard and display and the TPM, True Random number generation Counter which starts at zero when born, continuously updates, write to nonvolatile memory on shutdown SHA-1 160 bits record state of machine No monitoring of pins – perfect for fingerprint scans… TPM – great for multi-factor authentication Each TPM has unique secret RSA key burned in I/O Cryptographic co-processor Key generation HMAC engine Random number generator SHA-1 engine Power detection Opt-In Execution engine Non-volatile memory Trusted Platform Module (TPM) Volatile memory Packaging Figure13.11 13.12 TPM Component Architecture Figure Decrypted file 4. File released User application (performs decryption) Symmetric key 3. Key released Current platform software environment TPM 2. Verification Encrypted file Protected symmetric key Storage 1. Loading of encrypted key Figure13.12 13.13 Decrypting a File Using a Pr otected Key Figure Common Criteria for Information Technology Security Evaluation • Common Criteria (CC) for Information Technology and Security Evaluation o ISO standards for security requirements and defining evaluation criteria • Aim is to provide greater confidence in IT product security o Development using secure requirements o Evaluation confirming meets requirements o Operation in accordance with requirements • Following successful evaluation a product may be listed as CC certified o NIST/NSA publishes lists of evaluated products Common set of potential security requirements for use in evaluation Functional requirements Target of evaluation (TOE) •Define desired security behavior •Refers to the part of product or system subject to evaluation Class •Collection of requirements that share a common focus or intent Assurance requirements •Basis for gaining confidence that the claimed security measures are effective and implemented correctly Component •Describes a specific set of security requirements •Smallest selectable set Security Assurance “Degree of confidence one has that the security controls operate correctly and protect the system as intended. Assurance is not, however, an absolute guarantee that the measures work as intended.” Target audiences Consumers • Select security features and functions • Determine the required levels of security assurance Developers • Respond to security requirements • Interpret statements of assurance requirements • Determine assurance approaches and level of effort Evaluators • Use the assurance requirements as criteria when evaluating security features and controls • May be in the same organization as consumers or a third-party evaluation team • Assurance • Deals with security features of IT products • Applies to: Requirements Security policy Product design Product implementation • System operation • • • • System architecture System integrity System testing •Addresses both the system development phase and the system operations phase •Addresses the correct operation of the system hardware and firmware •Ensures security features have been tested thoroughly Covert channel analysis Trusted facility management Configuration management •Deals with system administration •Requirements are included for configuration control, audit, management, and accounting Trusted recovery Trusted distribution •Provides for correct operation of security features after a system recovers from failures, crashes, or security incidents •Ensures that protected hardware, firmware, and software do not go through unauthorized modification during transit from the vendor to the customer •Attempts to identify any potential means for bypassing security policy Design specification and verification •Addresses the correctness of the system design and implementation with respect to the system security policy EAL 1: Functionally tested EAL 2: Structurally tested EAL 3: Methodically tested and checked EAL 4: Methodically designed, tested, and reviewed EAL 5: Semi-formally designed and tested EAL 6: Semi-formally verified design and tested EAL 7: Formally verified design and tested Ensures security features work correctly and effectively and show no exploitable vulnerabilities Performed in parallel with or after the development of the TOE Higher levels entail: greater rigor, more time, more cost Principle input: security target, evidence, actual TOE Result: confirm security target is satisfied for TOE Process relates security target to high-level design, low-level design, functional specification, source code implementation, and object code and hardware realization of the TOE Degree of rigor and depth of analysis are determined by assurance level desired • Evaluation parties: o Sponsor - customer or vendor Preparation o Developer - provides evidence Initial contact between sponsor and developer for evaluation o Evaluator - confirms requirements are satisfied o Certifier - agency monitoring evaluation process • • Monitored and regulated by a government agency in each country Common Criteria Evaluation and Validation Scheme (CCEVS) o Operated by NIST and the NSA Conduct of evaluation Confirms satisfaction of security target Conclusion Final report is given to the certifiers for acceptance Phases Summary Physical Security • • • • Physical security threats o Natural disasters o Environmental threats o Technical threats o Human-caused physical threats Recovery from physical security breaches Physical security prevention and mitigation measures o Environmental threats o Technical threats o Human-caused physical threats Integration of physical and logical security o Personal identity verification o Use of PIV credentials in physical access control systems Trusted systems • • • • o Reference monitors o Trojan horse defense Application of multilevel security o Multilevel security for role-based access control o Database security and multilevel security Trusted computing and the trusted platform module o Authenticated boot service o Certification service o Encryption service o TPM functions o Protected storage Common criteria for information technology security evaluation o Requirements o Profiles and targets o Example of a protection profile Assurance and evaluation o Target audience o Scope of assurance o Common criteria evaluation assurance levels