Chapter 2: Access Controls PDF

Purchase date, warranty information Last update dates (firmware, hypervisor, etc.) Asset usage metrics Software Publisher Version number, service pack/hotfix number, and date of last update Digital signatures on installation packages License information Purchase date Install date In addition, operational security details should be collected, such as the type of data stored and processed on the asset, the asset classification and special handling require- ments, the business processes or missions it supports, and the owner, administrators, end users, or user groups nominally authorized to use it, and their contact information. There are of course many tools available that do these tasks or portions of these tasks. Most organizations already own many such tools. Consider the following: An Active Directory or Lightweight Directory Access Protocol (LDAP) server can provide a large portion of this information. Other integrated identity management and access control systems can provide some of this information and can be especially useful in identifying assets that aren’t under management but are attached (or attempting to attach themselves) to your systems. Vulnerability scanners, configuration scanners, and network mapping tools can find and provide basic information about all the hosts in the organization’s IP ranges. Tools that manage/track software licenses can perform a large portion of this task. Data loss prevention (DLP) solutions typically have a discovery capability that can serve this purpose. For gaps in their available tools, organizations can and do compensate with manual efforts, spreadsheets, and scripting to pull and tabulate asset data. Dedicated asset inven- tory tools usually provide this functionality and preclude the need for manual data pulls and tool integration. Regardless of the tool or combination of tools used, there should be one the organi- zation deems authoritative and final so that it can be referenced throughout the organi- zation. The information in this tool needs to be definitive. This is the data source to trust 46 CHAPTER 1 Security Operations and Administration if there is conflict between what other tools are reporting. This should also be the source used for official reports and other data requests, such as part of an audit. 1 Process Considerations Security Operations and Administration Let’s now look at some inventory management best practices. First, the organization must define the authoritative inventory list or system of record and define the frequency with which the inventory should be refreshed or updated. In addition to the regular interval inventory updates, it is also a good practice to ensure that the inventory management system is updated, and its administrator notified when assets are installed, removed, or updated/changed in a significant way. This can be accomplished in a different way for environments that make heavy use of virtualized components, including managed cloud service implementations. In these cases, use of automated tools to seek out, tabulate, and provision assets is often preferable; popular tools include Puppet, Chef, and Ansible. For on-premises assets, it is often helpful to augment the inventory process with the use of geolocation information/geotags or the use of RFID inventory tags. This can increase the speed and accuracy of locating an asset, especially during an incident when time is critical. Lifecycle (Hardware, Software, and Data) Although some legacy systems may seem to be lasting forever, it’s much more common that information systems assets of every kind have a useful economic life span, beyond which it is just not useful or cost-effective to continue to use it and keep it working. Once past that point, the asset should be disposed of safely, so as to terminate exposing the orga- nization to any risks associated with keeping it or failing to care for it. The typical systems development lifecycle model (SDLC) can be applied to hardware, systems software, applications software, and data in all of its many forms; let’s look at this from an asset manager’s perspective: The requirements phase identifies the key functional and physical performance needs that the system should meet and should link these to the organization’s mission, goals, and objectives. When any of these change, the asset manager is one of the stakeholders who evaluates whether the asset is at or past its useful economic life. During the design phase, the functional requirements are allocated to individual elements of the design; it’s worth considering at this point whether these compo- nents of the total system should be tracked as assets by themselves versus tracking the system as a whole or as a single asset. Participate in Asset Management 47 Development, integration, and acceptance testing quite often conclude with a list of identified discrepancies that must be tracked and managed. In effect, each open discrepancy at the time of systems acceptance is a lien on the overall value of the system (much as a mortgage or mechanic’s lien on your home reduces the equity you would realize from selling your home). Tracking those discrepancies is a form of tracking residual risk. Operational use presents an opportunity to appraise the value of the system; finding new uses for it increases its value to the organization as an asset, but if users find better, faster ways to do the same jobs instead, this in effect decreases the value of the asset. Maintenance and upgrade actions can extend the useful life of the system while adding to its cost. This is also true for ongoing license payments, whether as per- seat or site-wide licenses for software use. Retirement and safe disposal, and the costs associated with these, bring this partic- ular asset’s lifecycle and its asset management account to a closed state. Disposal must deal with the issue of data remanence, which refers to information of any kind remaining in the memory, recording surfaces, physical configuration settings, software, firmware, or other forms. This applies to more than just the familiar disks, tapes, and thumb drives; all hardware devices have many different internal nooks and crannies through which live data flows during use. Old-fashioned cathode ray tube (CRT) displays risked having images burned into their display surfaces. Printers have been known to go to the scrap dealer with fragments of previously printed documents, or impressions on their printing drums and ribbons of what they last printed, still legible and visible. Printed documents may need to be shredded or pulped. As a complication, you may end up hav- ing to store these retired assets, at a secure location, while awaiting the time (and money) to have a proper zeroization, purge, or destruction of the element to prevent an unautho- rized disclosure from happening. Hardware Inventory In many work environments, people and whole workgroups can move around within a large facility. People shift from one workstation to another or to larger (or smaller) spaces in another room or another building; some may even move to a different city or country or travel extensively. Hardware inventory needs to know logically and physically about each device, be it an endpoint, a server, a peripheral such as a printer or scanner or a removable storage device. Assuming for a moment that no MAC address spoofing or alteration is allowed, the identity of an individual device should remain constant; knowing that it’s currently attached via a certain IP address and that it is (or is not) 48 CHAPTER 1 Security Operations and Administration connecting through a VPN is part of knowing logically where it is. But…knowing phys- ically what desk or tabletop, rack, room, building, or continent it’s on (or in) can be 1 problematic. It’s prudent to avoid procedurally intensive ways to address this problem, as the German military found out a few years ago. They went from simply allowing their Security Operations and Administration military and civilian staff to just pick up and move their desktop and laptop computers from office to office, as temporary shifts in duties arose, and instituted a work-order pro- cess as a way of capturing location information for their asset inventory. This added days of work as each move had to have a form filled in, which was sent to an approvals and dispatch center; then had to have a worker move the equipment; and finally have the form sent back to the user to sign off that the move was now complete. Attribute-based access control (ABAC) may be a smarter solution to such problems, although it may require endpoints that can be trusted to accurately report their physical location without end-user intervention. I cannot overstress the need to know the physical location for infrastructure elements such as servers, routers, switches, and such, to as detailed a level as possible. Precious time can be wasted during an incident response by having to search for which room, which rack, and which unit or position in the rack is the device that’s been sending up alarms (preferably not sending up smoke signals). It’s also especially important to note which power distribution panel or circuit breaker box serves each equipment rack or bay and which power conditioning systems feed which distribution panels or breaker boxes. Software Inventory and Licensing Software and firmware come in many different forms; almost without question, all of these forms should be under the right combination of configuration control, configura- tion management, and asset management. Between those three processes, you’ll have a very good chance to know that all of your software elements: Have been protected from unauthorized changes Have had all required changes, patches, and updates correctly applied Have had all outstanding discrepancy reports or change requests reviewed and dispositioned by the right set of stakeholders and managers Where each element is, physically and logically, how it’s being used, and whether or not it is up to date You’ll also know, for each software element, whose intellectual property it is and whether there are license terms associated with that ownership interest. For each license, you’ll need to know the detailed terms and conditions that apply and whether they apply to all copies you’ve installed on any number of devices or to a specific maximum number of devices; the license may also restrict your ability to move an installed copy to another Participate in Asset Management 49 system. The license might be seat limited to a specific number of individual users or capacity limited to a maximum number of simultaneous users, maximum number of files or records, or other performance ceilings. Many modern applications programs (and operating systems) facilitate this by using digital signatures in their installation processes so that each installed and licensed copy has a unique identifier that traces to the license identifier or key. Software license inventory management tools can easily poll systems on your network, find copies of the application in question, and interrogate that installation for its license and identifier information. This can also find unlicensed copies of software, which might be legitimate but have yet to activate and register their licenses or might be bootleg or unauthorized copies being used. Proper software license management and software inventory management can often save money by eliminating duplicate or overlapping licenses, or by restricting usage of a particular app or platform strictly to where it’s needed. Data Storage Whether you think of it as data or information, it is either in use, in motion, or being stored somewhere in the information architectures and systems you are keeping safe and secure. Data can be used by endpoints, servers, or the infrastructure itself. Data is in motion when it is being transferred across networks, communications links, or even to and from a storage device temporarily attached to an endpoint computer or smartphone. Data can be stored – be at rest – in endpoint devices, in removable media, and in storage subsystems that are part of an on-premise network or hosted in a public or hybrid cloud. Chapter 7, “Systems and Application Security,” will look in greater depth at security issues relating to data storage in the cloud and within your networks and their servers. What remains is the vexing problem of data storage on paper and on removable storage media and devices, and when those storage media and paper documents are being moved around. Information Lifecycle Information has a natural lifecycle, but as with most things in the IT world, there are many different models for this lifecycle, with different emphasis placed on different phases of the data’s existence. For example, ISO 27002 defines this cycle with five phases: creation, processing, storage, transmission, and deletion/destruction (see Figure 1.2). Other models, such as those built into many systems management platforms such as SAP, may combine creation and use with processing; then add a retention phase in which the data is not actively used but cannot be disposed of because of legal, regulatory, or liability reasons; and finally end with a disposal and destruction activity. 50 CHAPTER 1 Security Operations and Administration 1. 1 Creation & Origination Security Operations and Administration 5. 2. Deletion & Processing Destruction 4. 3. Transmission Storage FIGURE 1.2 ISO 27002 phases Security is an important consideration at every phase, but the level of importance can vary, depending on the phase. The formats and media used in the various phases can also affect the security considerations. Consider, for example, design documents for a new product or technology. When those documents/data are new, they are valuable and actionable, especially if a competitor acquires them. Once the product or technology is in production and is being sold on the market, those same documents could be near the end of their lifecycle. At this point, one could argue that the documents would do less damage in the hands of a competitor, but they still need to be afforded some level of protection, right up to the moment they are destroyed. In this example, even though the creators have benefited from the “rush to mar- ket” advantage, the design documents themselves could still contain sensitive data, such as a proprietary production method, which the organization plans to reuse in future products. There are several important points to take from this example. First, the security impact may vary depending on where the information is in its lifecycle. Next, even though the impact may vary, there can be negative outcomes for the organization at any phase. Finally, phase five, the deletion and destruction phase, is important because destruction of unneeded assets reduces the organization’s attack surface. Data at the end of its lifecycle only introduces risk, with little to no benefit. The lifecycle view shows that datasets (or information assets) are constantly going back and forth from storage to use; throughout that ever-repeating cycle, your systems designs should protect the information while it is at rest, in use, and in motion. Cur- rently, well-chosen encryption systems can protect data in motion and at rest and by means of digital signatures offer the stored copies protection in time as well. (Chapter 5 Participate in Asset Management 51 goes into this in further detail.) However, thus far there are not many solutions to protect data while it is being used from compromise or loss, since most operations on data and its use by humans needs to have the meaning of the data readily available. Apply Resource Protection Techniques to Media Protecting the information on storage media requires that you can control or limit the onward use, copying, or other redistribution of that information; it also requires you to protect your systems from being contaminated by information from a classification level that does not belong on your systems. For example, the Biba and Bell–LaPadula access control models to show how different models emphasize confidentiality or integrity. Both choices can be undone by putting the wrong level of information onto the wrong remov- able media and then introducing that media into another system. You’ll see a variety of standards and practices in use that may place different emphasis on protecting either the information (and its confidentiality, nonrepudiability, or integrity) or the systems (by pro- tecting their integrity, and hence their availability and authenticity). Before covering the methods for properly managing media, it’s important to acknowl- edge that these methods will vary based on the types of media used. The umbrella term of media or information system media could mean legacy analog formats, such as hard-copy documents, photos, and microfilm. It could also (more likely) be in reference to a wide range of digital formats, such as external hard drives, floppy disks, diskettes, magnetic tape, memory cards, flash drives, and optical disks such as CDs, DVDs and Blu-Ray disks. As you might expect, making secure but removable media work requires successfully integrating your security classification schema, your device-level identity management and access control, and the management of all endpoints’ capabilities to use removable storage—including on the endpoint itself. Marking Handling sensitive or classified information involves everything necessary to meet its pro- tection requirements; handling storage media refers to all processes, be they human, elec- tronic, or mechanical, which are involved in mounting, dismounting, storing, shipping, using, reusing, and ultimately destroying the media. This protection requires a combina- tion of marking the media and establishing and using administrative and logical processes that perform those tasks in controlled, reliable, and auditable ways. The marking achieves nothing without the procedures being understood and used properly! Marking involves labeling in both human-readable and machine-readable manners so that it is immediately obvious what the highest security classification level of data on that media can be and should be. Humans are known to put “for unclassified use only” disks into drives and then write secret, proprietary, or private data to them, either deliberately as part of an exfiltration attempt or accidentally. The labeling should clearly link to the 52 CHAPTER 1 Security Operations and Administration proper handling procedures for that level of security classification. Done properly, your device-level identity management and access control systems can then use this marking 1 to authenticate the media when it is first mounted and then authorize each attempt to read or write data or metadata to it. Security Operations and Administration It’s strongly recommended that your IT or security teams be the ones who purchase, label, initialize, and inventory storage media used for sensitive, proprietary or other data security classifications your company uses. When teamed with user-facing policy direc- tives, this can significantly reduce the compromise of classified information due to a user forgetting to properly label a piece of media. ✔✔ Colorize to Classify Marking media might become complicated, depending on the media used. For instance, it might be possible to include a significant amount of information on the label of a 3.5" floppy disk, but much, much more difficult to put that same information on the label of a USB flash drive that is the size of a thumbnail. Quite often, it’s much more effective to use color schemes as a visible part of media security marking, when the media itself can be readily purchased in a range of colors suitable for your organiza- tion’s security labeling needs. Many media vendors can also prelabel the physical media itself to meet your needs. Protecting Consistent with the least privilege and separation of duties concepts discussed previously, your organization should restrict access to and usage of removable media to specifically authorized staff members who need it for their daily duties, based on their specific roles. To do this, there must be an element of physical protection and storage that is com- mensurate with the sensitivity and classification of the data on the media. Here are a few examples, illustrating different levels of protection: Backup copies of audit logs are kept in a locked desk drawer or cabinet, where the key is available only to administrators who may need to review the logs. Signed hard-copy health insurance forms are in a locked file cabinet in a room restricted to HR staff via proximity-badge access. An external hard drive with classified data on it is fully encrypted and is in a locked safe in a protected area, accessible only to users with appropriate security clearance and need to know. The encrypted files can be decrypted only on sys- tems that are cleared for using information at that level and then only when being used by a user with matching privileges. Participate in Asset Management 53 As you can see in the examples, different layers of both physical and logical access con- trol can and should be provided to media to meet your information security needs. There are additional measures to consider, based on the sensitivity and criticality of your media. You may need to create redundant copies of critical media to mitigate accidental damage or loss. Suitable encryption and other techniques can protect the classified data while it is at rest (stored on the media) and in motion between the media and the systems that are processing it (and making it available to users). Remember, too, that all storage media and technologies suffer degradation over time, resulting in data loss. Your data integrity, availability, and retention needs may drive you to establish a media rotation strategy, which periodically moves the files (the in-use set and the backup copies) to new, fresh media. (Data centers have been doing this since the 1960s, as they discovered that reels of magnetic tape quite literally saw bits flaking off when they hung in storage for too long.) Finally, you should treat the collection of all of your sensitive, critical information and the media it is stored on as a library of assets and define formal processes for periodically verifying your inventory of media, for formally authorizing users to check media in and out of the media library, and for leaving an audit trail. These processes should be followed until the media is either sanitized and then downgraded for uncontrolled use (not recommended—it’s a false economy!) or destroyed for disposal, using approved equipment and methods in either case. Transport Your organization needs to have a defined set of procedures for protecting media when it is transported outside of controlled or restricted areas. These procedures should define the check-in and checkout accountability mechanisms used for transport, as well as the documentation requirements of the transportation activities. You should also explicitly define what information must be captured or logged upon checkout, during transport, and upon check-in of media, which might include details such as who requested the transport and who was responsible for the media during transport. Any staff or courier transporting media should clearly understand the restrictions applied to the transport (such as approved travel methods, routes) as well as special han- dling and packaging considerations, based on media type, to protect it from hazards such as moisture, temperature, and magnetic fields. This also includes when, whether, and how encryption should be used during transport. Couriers should also understand your rules on deviations from procedures in the event of unforeseen circumstances encoun- tered during such transport. Transport procedures should be clear as to when appointed custodians are necessary, who the approved custodians or couriers are, and how to verify identity if external couri- ers are used. Consideration should also be given to when and how the responsibilities of the custodian can be transferred to another, as well as specific points of contact to whom the media can be transferred at arrival. 54 CHAPTER 1 Security Operations and Administration Sanitization and Disposal 1 The topics of media sanitization and disposal overlap and are interrelated. There is a time in the information lifecycle when certain data is no longer needed, and having this data Security Operations and Administration sitting on media for no reason presents an unacceptable risk. If there is no benefit, why accept even the slightest risk that the media could be compromised? At that point, the information must be destroyed by sanitizing or zeroizing the media; the media may be returned to your library as reformatted, empty, but suitable for reuse with information at a security level consistent with the media’s marking or destroyed if the media is past its eco- nomically useful life as well. So, what are the differences between the two? The first difference is the reuse scenario. According to NIST 800-53, media should be sanitized “prior to disposal, release out of organizational control, or release for reuse.” Disposal of media doesn’t acknowledge a need to reuse the media, but sanitization does. Blank, new media might cost $50 to $3,000 or more apiece, so it may be worthwhile to have effective reuse and sanitization strategies in place. With the rapidly increasing capacity and decreasing cost of solid-state drives and flash media, many organizations choose verifiable destruction rather than risk an incomplete sanitization of such media. Destruction can also be done faster and at less cost in most cases. The next difference is in the methods. The sanitization methods are less physically destructive than disposal methods. For example, sanitizing nondigital media, such as paper documents, is accomplished by removing sensitive pages or entire sections or by redacting or obscuring specific text. In contrast, disposal of paper documents would entail cross-shredding, pulping, or burning the papers entirely. Sanitizing digital media, such as hard drives, would mean overwriting each sector and byte of the drive many times with random characters. (The NSA has been known to call this process zeroization, even though it doesn’t actually recommend writing nothing but zeros to the media; this would risk a missed block or sector being completely readable.) Disposal of hard drives, in contrast, entails either degaussing the drive, physically abrading or chemically corroding the surface of the disk platters, or breaking the entire drive in a powerful shredder. Even when degaussed or abraded, disposal of sanitized media may be constrained by local laws, including any limitations on the search of trash disposal sites with or without a search warrant. Note Degaussing does not work on a solid-state drive (SSD) or optical disk. Another slight difference you can see in the NIST verbiage is that sanitization is often a defense-in-depth approach to precede disposal and augment it as a security control. Imagine, for example, a scenario where a hard drive was not effectively destroyed by the organization’s normal disposal method or was, for example, intercepted by a curious or Participate in Asset Management 55 malicious person in the chain of custody. Even if the drive wasn’t destroyed but had been previously overwritten many times with random characters, it may still be unreadable, and the sanitization is a good mitigation for the failure in the disposal process. Having discussed the differences, what are the commonalities between sanitization and disposal? Essentially, everything else. The goal of both sanitization and disposal is to ensure that the data previously on the media is not readable or recoverable. They should both hap- pen according to formal processes that review, approve, document, and verify the sanitiza- tion/disposal. In both cases, the methods and tools should be commensurate with the data stored on the media. This also includes the removal of external markings and labels. For both sanitization and disposal, the sensitivity of the data on the media should drive how rigorously you apply these processes and how thoroughly you control it proce- durally. In some cases, also consider that it may be less expensive to apply the more strin- gent sanitization or disposal method to all media than to spend time separating them. Both sanitization and disposal use specific tools, whether software tools, grinder, shredder, degausser, etc. These tools need to be periodically tested to ensure they are effective and that the media/remnants cannot be read or restored. When storing and collecting media prior to sanitization or disposal, consider affording additional protection above and beyond normal media classification and marking. If there is a large quantity of nonsensitive information in one place, it can become more sensitive by aggregation. ✔✔ Media Disposal and Information Retention Must Match Almost every category of corporate or private-sector sensitive or classified information has to have a retention strategy defined for it, as part of keeping the organization compli- ant with a growing and sometimes bewildering body of law and potentially conflicting stakeholder interests. Make sure that your information library procedures, including the ones for destruction of information and disposal of media, match with those retention requirements. If they don’t, you’ll need help from senior management and the organiza- tion’s legal team to find an acceptable solution. IMPLEMENT SECURITY CONTROLS AND ASSESS COMPLIANCE Although it seems a bit of an oversimplification to do so, you can characterize the world of information security controls (also known as risk mitigation controls) by their mix of phys- ical, technical (or logical), and administrative elements. For example, a perimeter fence 56 CHAPTER 1 Security Operations and Administration is both a physical investment in a control technology and its accompanying procedures for a periodic inspection, including “walking the fence line” by the security patrols and 1 repairing damage by Mother Nature, vandals, or intrusion attempts. Technical or logical controls are the software and data settings, the jumper plugs or control switches, or other Security Operations and Administration device or system configuration features that administrators use to get the software and hardware to implement a security control decision. Windows-based systems, for example, use software-defined data structures called group policy objects (GPOs) that apply logical rules to subjects and objects in the system to exert security control over their behavior. Most network devices are logically configured by interacting with their GUI, a built-in web page, or a command-line interpreter, to accomplish the technical configuration of that device so that it does its part in carrying out the organization’s security policies. Note It’s helpful to remember that a physical control interacts physically with the subject or object being controlled; technical and logical controls interact with data flows and signals being sent around the system as ways to control the logical behavior of software and hardware. Chapter 3 will focus on how you choose what mix of physical, logical, and adminis- trative controls to build into your security architecture; here, we’ll focus on them after you’ve installed them and declared them operational. Regardless of the type of control elements involved, compliance can be measured or assessed by the same set of techniques: review, audit, exercise, and operational evaluation. Help-desk trouble tickets, user complaints or suggestions, the “police blotter” or daily logs kept by your security teams, and many other sources of information should all be subject to review and audit. Performance metrics can also be adopted (preferably in auto- mated ways) that can alert management when controls are not being used effectively, as indicated by increasing rates of incidents, error rates, problem reports, and end-user dis- satisfaction with system usability and reliability. Don’t forget to keep an eye on customer or client behavior and input: A decline in orders, transactions, or web page hits may be as much about the quality and price of your products as it is about the security (or lack thereof) of your information systems and practices, as seen by your customers. Technical Controls In all cases, you should first have an administrative (people-facing) control document, such as a policy statement or a procedure, that provides the justification and the details you need to configure, operate, inspect, and update all of the technical settings that imple- ment the electronic aspects of your security architecture. These include both the networks, servers, and endpoint technologies, such as software Group Policy Objects, parameter files, access control lists, or even jumper and patch panel settings. Also included are the Implement Security Controls and Assess Compliance 57 programming, options, and controls for fire and safety alarm systems, motion detectors, entryway alarms, power conditioning, and environmental control systems. (Remember, it was through a maintenance back door in the heating, ventilation, and air conditioning systems that attackers were able to gain entry into Target’s systems in 2013.) Two of the most common technical controls used in many security strategies are related to setting time limits on user activity. Session timeouts or inactivity lockouts can be implemented on an endpoint device level, on a per-user ID level, or by indi- vidual applications platforms, servers, or systems. They force a user to take a positive action to reconnect or renew a login (and go through some or all authentication factor steps) to continue, once their device, session, or use of that resource has been inactive for a specified period of time. This can be frustrating to users when they’ve come into a system via SSO authentication, gaining initial access to a set of resources and applications at the start of their workday but then having to repeatedly log back in again when they’ve let individual sessions with specific apps or servers go idle for too long. Session timeouts provide protection against the “lunchtime attack,” which got its name from an intruder being able to wander around an office building and find computers unattended but still logged into the system during lunch breaks. Device-level timeouts on company-managed endpoints are typically set for short peri- ods, such as 10 minutes, based on similar reasoning. Specific applications platforms and the portals that your users access them through may need to impose their own timeout periods and choose whether to use timeout warning reminders, based on spe- cific systems security needs. Another time-based technical control, the merits of which are hotly debated, is password aging; this sets a time period (usually measured in days, not minutes) after which a user must change their password. Other password policy settings can limit pass- word reuse as well. Password aging, length, complexity, or other password characteristics should be determined as part of your integrated approach to identity management and access control; proper implementation of multifactor authentication, for example, may provide greater security and ease of use than complex, rapidly aging passwords were once thought to provide. All of these settings should be subject to formal configuration management and con- trol and documented in some fashion so that an incident response team, network opera- tions staff, or the IT team can quickly refer to them to determine whether the alarms are sounding due to a misconfigured control or because a security incident is occurring. Physical Controls Physical controls are things you can touch (or bump into); they are the walls, doors, locks, fences, mantraps, concrete barriers, and their relative placement in your overall physical arrangement of a facility. By themselves, physical security features provide 58 CHAPTER 1 Security Operations and Administration deterrent, prevention, and containment capabilities; to get your money’s worth out of them, most organizations add monitoring equipment such as cameras, motion detectors, 1 alarms, and people (and perhaps security canine patrols). As more robots and autono- mous mobile devices enter the workplace, physical access controls must be able to cope Security Operations and Administration with their presence and movements. Gluing that all together requires administrative controls in the form of policies, procedures, and control documentation. It also relies upon the human element—the monitors, the watch-standers, and the administrative and technical people who make it work and who use it to secure and protect the organization, its people, its information, and its assets. ✔✔ Human Vigilance—Keep It Working for You Whether you consider it part of your physical or administrative control systems, the human element in your security architecture can and should provide significant return on your investment in it, which you can achieve by treating them as professionals. Recruit them as if they matter to you (which they do!). Make sure that initial onboarding and training informs, empowers, and inspires them. You have a leadership opportunity with everyone involved with security operations, whether you’re their supervisor or not. Step up to that challenge, work with them, and lead them as a team to be part of what keeps everybody’s jobs secure. No matter what functions they perform or whether they stand around-the-clock watches and patrols or only work normal business hours, they can be pivotal to keeping your systems and your company safe—or become some of the weakest links in your chain of security if you ignore them or let others in the organization treat them shabbily. And if it’s your first day on the job, be sure to treat each and every one of them as the helpful, dedicated professional that they are. The paybacks of this strategy can be unlimited. Physical security architectures usually place high-value assets and systems within mul- tiple, concentric rings of physical perimeters. Entry onto the property might require going past a guard post; checkpoints at the entries to individual buildings on the property would authenticate the individuals attempting to enter and possibly conduct a search of the per- sonal property such as briefcases or backpacks under their control. (Most jurisdictions do consider that owners or managers of private property have the legal right to require that visitors or staff voluntarily allow a search of their person and belongings and deny entry to those who decline to cooperate with such a search.) Once inside, lateral movement within an area or access to high-value areas such as documentation or software libraries, financial operations centers, server and network rooms, or security operations control Implement Security Controls and Assess Compliance 59 centers are further restricted, perhaps requiring two-person control as part of authentica- tion procedures. Layer by layer, these cascades of control points buy time for the defend- ers, time in which any errors in authentication can be detected or subsequent attempts by the subject to exceed authorized privileges generate alarm conditions. Controlled entry systems, such as mantraps and turnstiles, are electromechanical sys- tems at heart. On the one hand, these must interface with some portion of your identity management and access control systems to be effective; on the other hand, they need routine maintenance, as well as remedial maintenance when they fail during use. In most cases, human guards or controllers are present in the immediate vicinity of such control points. Controlled egress systems may employ the same physical, logical, and administrative tools as used to control entry into and movement within a facility; they bring the added benefit of controlling inventory, equipment, software, or data loss (sometimes called shrinkage by wholesale and retail businesses), by both deterring and preventing unau- thorized removals from occurring. This usually requires a degree of search of property as it leaves the controlled area. A growing number of high-technology firms, especially in biotechnology, rigorously enforce controlled egress and search as vital components of protecting their intellectual property and competitive advantage. Video and audio monitoring systems have become standard elements in most secu- rity systems—and all the more so as the costs of fully digital systems have become much more affordable. Even the small office/home office (SOHO) entrepreneur can afford a multicamera, digital video recorder security system, complete with Internet interfaces for remote monitoring. Many security cameras now come with infrared LEDs that provide surreptitious illumination of the scene, which improves monitoring significantly without needing to add visible light floodlighting systems and their power distribution and control elements; note that after keeping the lenses clean, proper lighting is essential for useful image quality. Inspection and maintenance of physical control systems is vital to continued security. Administratively, there should be no surprises here; if a maintainer or inspector shows up, your on-shift, on-site guards and monitors and the security control force all need to first authenticate their identity and further confirm that they’ve been properly called out or dispatched to perform a specified set of tasks. All physical control systems elements should be documented and under formal con- figuration management and control appropriate to their physical nature. Concrete block exterior walls, for example, should not be subject to having holes drilled or cut into them without proper authorization. The security department might not control or manage all of this documentation or the change management processes for the structural elements of the physical security aspects of your systems; regardless, your organization’s security needs suggest how closely the building maintenance teams and the security teams need to work with each other. 60 CHAPTER 1 Security Operations and Administration Administrative Controls 1 In most organizations and the cultures they are rooted in, there is a natural hierarchy of guidance and direction, starting with broad, sweeping, and visionary statements that Security Operations and Administration get progressively less motivational as they become more prescriptive. Subsequent layers become proscriptive, tending to have as many “thou shalt nots” as they have “shall” state- ments in them (if not more). Although the names for many of these layers may be differ- ent in different settings and cultures, it’s still reasonably useful to expect the same basic layers of policies, standards, procedures, baselines, and guidelines. Policies Policies are at the heart of what the organization is trying to accomplish. At a high level, policies provide critical instruction to senior executive management to implement mea- sures to achieve external compliance expectations or support the larger strategic vision of the organization. This layer of senior management then promulgates these vision statements down to more tactical and operational managers both as policy statements and in finer-grained direction. As governance documents, the responsibility for creating and maintaining policy rests with the board of directors or other formalized group of senior stakeholders and leaders. As such, policies are one of the ways in which the board demonstrates due care. Boards can and often do delegate or direct that executive or oper- ational management develop these policies and bring them back to the board for review and endorsement. Policies, relative to other organizational documents, are less likely to change. They provide consistency to the organization’s management, allowing the leadership to shape standards and create procedures that achieve the policy end. They should provide man- agement with sufficient flexibility to adapt to new circumstances or technologies without a policy revision. Mature organizations routinely review their policies within their governance pro- cesses. Changing external compliance expectations or shifts in business strategy almost always require changes in statements of policy and vision. Additionally, these same exter- nal factors may cause the organization to confront or consider changes to their previously established strategic goals and objectives, which will probably drive more policy changes. The policy review process must address the changing needs of external stakeholders to support predictability in execution of the policies by management. The use of the term policy when implementing security practice in an organization is often confusing. For example, a password policy may, or may not, be of interest to the governing organization—but it certainly would be of interest to the management team! The organization’s governance structure would likely express interest in ensuring access controls are present and that the compliance expectations are appropriate to the Implement Security Controls and Assess Compliance 61 organization’s needs at the policy level and leave to management the decision of how many times a password should be rotated. That management chooses to refer to the out- come of their due diligence as a policy is an organizational decision. Sometimes referred to as subpolicies, these amplifying instructions further set behav- ior expectations for the organization. Some of the areas that might be addressed include passwords, cryptography, identity management, access control, and a wide range of other topics. The critical distinction is whether the instruction comes from the governance body (making it a policy) or whether it is derived from a higher-level policy by the organi- zation’s management. This broad use of the term policy reflects one of the major challenges in our indus- try. A lack of a common language for information security practice has been repeatedly identified as one of the factors inhibiting the development of a common body of practice in the information security community. It is further complicated in an international environment where translations and cultural differences affect how people perceive infor- mation. In addition, the various standards bodies have published specific definitions for information security terms that may have nuanced differences between each other. And if that’s not confusing enough, there are many instances of operating systems configuration settings that are also called policies. Standards Once the organization has decided what it wants to accomplish, management can start to perform tactical planning and operational activities to carry out the intent of the policies. One tool to support efficient management of resources is the use of standards. Standards simplify management by providing consistency in control. External standards are ones developed outside of the organization, usually by governments or industry association standards-setting bodies such as the IETF or IEEE. These provide the world with a uniform vision, purpose, and set of details about the issues that the standard focuses on. Companies can also generate their own internal standards, which they may choose to make as mandatory on all of their systems. Regardless of where the standards come from, they are downward-directed by management onto lower levels of management and super- vision to support the achievement of the organization’s strategic goals and are tied directly to the organization’s policies. Standards also represent a consensus of best practice, as understood by the body that issues the standard. Standards may also be required as part of legal or regulatory needs or because a contract with a key customer requires the standard to be applied to work performed under that contract. Private organizations may be required to adopt certain standards to do business in a particular market. For example, if an organization wants a web presence, it has to take into account the standards of the World Wide Web Consortium (W3C) in developing applications. 62 CHAPTER 1 Security Operations and Administration While standards are a management tool, standards often evolve out of organizational practice. For example, selecting a particular vendor to provide a product may force a 1 standard where none was originally contemplated. De facto standards often evolve inside organizations as different parts of the organization adopt a new technology, not as a con- Security Operations and Administration scious management decision. Well-structured standards provide mechanisms for adaptation to meet local condi- tions. Through the use of baselines, an organization can shape a standard to better reflect different circumstances. Baselines enable the delegation of decision-making within strict parameters to lower levels of management. Nevertheless, standards are directive in nature; compliance is not optional. At most, the standard itself and the contractual or legal requirement to abide by it may specify ways in which the application of the standard can be tailored to the task at hand. Orga- nizations that adopt standards may also be required by those standards, by contracts, or by other compliance needs to monitor the successful application of and compliance with those standards. Procedures Procedural documents provide highly detailed task-oriented instructions. Procedural documents are useful when a high degree of compliance is necessary and the precise steps to achieve the outcome are not readily apparent to individuals not familiar with the environment. Management, as part of its diligence responsibilities, enforces organizational procedures through routine oversight and audit. Compliance is not optional, and well- structured organizations track compliance with procedural steps. In certain environments, procedural compliance is achieved by using various separation- of-duties methods. For example, in cloud environments, an organization might require that every action applied to the cloud environment is performed by using an approved configuration management script, such as a Chef recipe or a Puppet task, while further dictating that the author of a script cannot be the same individual who approves the script. Note, too, that the word procedure is also used by software developers and programming languages to refer to a unit of software, such as a function, a subroutine, or a stored query. Baselines Some organizational cultures refer to a tailored version of a standard as a baseline. Typ- ically, tailoring of a standard reduces the requirements set by the standard; if additional requirements are needed, it is best practice to put them into some other document, such as a local or internal standard. Once a baseline has been established, any deviation from the baseline should be formally approved through the organization’s change manage- ment practice. As with standards, baselines establish a compliance expectation. Implement Security Controls and Assess Compliance 63 As a subset of baselines, security baselines express the minimum set of security con- trols necessary to safeguard the information security requirements and properties for a particular configuration. Scoping guidance is often published as part of a baseline, defin- ing the range of deviation from the baseline that is acceptable for a particular baseline. Once scoping guidance has been established, then tailoring is performed to apply a par- ticular set of controls to achieve the baseline within the scoping guidance. The term baseline can also refer to a reference set of systems components; the inven- tory of software installed on a server by the vendor, at the time when the server is first turned on and configured, is an architectural baseline. Guidelines Guidelines are necessary when an organization determines that some level of flexibility in implementation is necessary to achieve business objectives. Guidelines often rely upon best practices for a particular discipline or are the codification of an organization’s experience in a particular area. Guidelines may be useful when a range of options exist to achieve a particular control objective and it is acceptable to encourage creativity and to experiment to compare the effectiveness of different options. Guidelines may also be useful when the organization’s staff has a broad base of experience and a shared vision for an outcome. In that case, the explicit directions of procedures, standards, and baselines may provide too much struc- ture and impede the adoption of more efficient methods. There are many sources of guidelines for information security practice. Certainly, the CISSP Body of Knowledge is one, as it reflects a broad range of security practices but is not prescriptive inside an organization’s information security environment. The ISO/ NIST/ITIL frameworks are often leveraged as guidelines; however, they may become policies or standards if the organization has a compliance expectation. Other sources of guidelines include manufacturers’ default configurations, industry-specific guidelines, or independent organizations such as the Open Web Application Security Project (OWASP) work in software development. There is no single, correct answer for the number and breadth of policies, standards, baselines, procedures, and guidelines an organization should have. Different regulatory environments, management expectations, and technology challenges will affect how the organization expresses and achieves its goals. Periodic Audit and Review There are two major shortcomings with most human-facing procedural and adminis- trative controls for security and risk mitigation. The first is that in their human-facing form as an end product, they invariably end up being anywhere but right at the point of 64 CHAPTER 1 Security Operations and Administration contact between the humans involved and the vulnerable system element the adminis- trative controls are designed to protect. Policies and procedures distributed on paper or 1 as email attachments end up being lost or buried in a desk drawer or folder tree and for- gotten about. Signs and warning placards catch the eye during the first few days or weeks Security Operations and Administration after they’ve been posted, but after a while, the human mind tunes them out; they’re just part of the visual clutter of the background. Because of these shortcomings, it’s good to audit your administrative controls with an eye to separating them into two major categories: those that direct or require a real- time action, such as emergency notification and incident response; and those that provide longer-term guidance for behavior, such as inappropriate or unauthorized use of company-provided assets and resources. That first category represents opportunities for some smart investment to ensure that just the right amount of policy guidance, direction, and constraint is at the right fingertips at the right time. Audits Audits are structured reviews that compare a set of security and risk controls, and the systems that they protect, against a controlled administrative baseline. This baseline can include inventories, performance standards, compliance standards and requirements, quality measurements and standards, or process maturity models and standards. Informal audits can be used as part of troubleshooting, to improve organizational knowledge of its own systems, or to gain insight into opportunities for improvement. Informal audits do not require the use of outside auditors who are trained and certified for the type of audit being performed. Formal audits, by contrast, are typically conducted to meet legal, reg- ulatory, or contractual compliance needs, such as those imposed by governments or the organization’s finance or insurance providers. Audits produce a report, which is typically addressed to the management or leadership levels of the organization that requested the audit. Although the structure of these reports can vary considerably, they usually include an executive summary of the audit, key findings, issues or discrepancies that need to be resolved, and any recommendations as appropriate. Audits can place a significant burden on information security operations and support teams. Typically, extensive preparation is required to identify the audit baseline or stan- dards that will be used and ensure that the auditors will be able to access all of the items being audited. Workspaces will need to be provided for the audit team, and the auditors may require special access and privileges to the IT elements being audited. They may also need to have IT systems to use for gathering and organizing audit data and to pro- duce and report their findings. Implement Security Controls and Assess Compliance 65 Exercises and Operational Evaluations Things change; that is the only constant we have in life. The proficiency and currency of the tacit knowledge within your team changes with time; the threats change how they seek opportunities that meet their needs and how they attempt to exploit them. Your systems change, and sometimes not for the better as they age in place. For these and many other reasons, it’s wise to establish a process of exercising and evaluating security and risk mitigation control systems, in as realistic an operational setting as you can manage without unduly disrupting normal business operations. A properly designed and well-considered exercise and operational evaluation plan should gain the support of management and leadership; their guidance and sponsorship are crucial to make time and talent available to plan and conduct such activities. Be sure that each plan closes with a thorough post-event debrief and analysis, producing documented recommendations or action items to finish the job of learning what each exercise or evaluation just finished teaching you and the evaluation team. PARTICIPATE IN CHANGE MANAGEMENT Change Management or Configuration Management? These two terms are quite often confused with each other or used as if they are inter- changeable; in point of fact, it depends upon the culture and environment you’re in as to which name is best to use. In business and leadership development contexts, change management (and change leadership) involves motivating, guiding, and leading people to change the ways they perceive their work and their systems and then further leading and guiding them toward making changes in those systems and in themselves. In these same contexts, configuration management is about taking a defined set of hardware, software, information, and even people skills and tasks, each of which has its particular collection or configuration of settings, options, parameters, and feature selections, and changing it into the same set of elements with different configuration settings. When you talk about IT change management and what you really mean is changing an IT systems’ technical configuration into another configuration, it may be less confusing to talk about this as IT configuration management rather than IT change management. (Fortunately, nobody seems to talk about leading people to behave differently as “recon- figuring” them or managing that growth and development as “configuration managing” the HR assets!) 66 CHAPTER 1 Security Operations and Administration In an effort to reduce confusion, throughout this book I will refer to decisions about 1 changing the configuration settings of an IT system as configuration management. (Change management, in the sense of organizational mission, vision, purpose, and cul- Security Operations and Administration ture, is beyond the scope of this book.) As with many other topic areas, configuration and change planning and management present opportunities for you to work with the people around you, and with the pro- cedures they already have in place, to understand what meanings they are implying by their use of certain terms. Guide them if you can to clarify, remove ambiguity, and become more aligned with industry-standard terms and meanings. Configuration management and its partner process configuration control together keep a system and all of its elements managed in a cohesive, controlled way as changes, updates, or repair actions take place. Configuration management is a responsibility of both due care and due diligence and is vital to asset management. It is also a high-payoff set of process investments to make for improved information systems security. Configu- ration management ensures that the right stakeholders have made informed decisions to make changes, apply patches, or delete elements of your systems; configuration control ensures that those directed changes get made and that no other changes are allowed to take place. Configuration management has perhaps the largest and most direct impact on an IT system’s security posture. Without an active and effective configuration management and configuration control (CM/CC) system in place, your systems are essentially unmanaged and vulnerable. Consider as your starting point that straight from the shipping cartons, the default settings on all of your IT hardware, software, firmware, and data are often unsafe. One simple misconfiguration such as leaving a guest account open can bypass all other security controls. If by chance the new equipment or software you install is set up correctly and has no exploitable vulnerabilities still exposed, without configuration control, subsequent changes to that system and other systems it interacts or coexists with can re-expose those factory default weaknesses. Don’t get the wrong impression here— without those factory or vendor default settings in place, you’d never be able to install and get the system up and running the first time. Once you do, of course, change them and lock them down tight. The record-keeping that is the backbone of a good CM/CC system has another great payoff waiting for you, in the event that disaster strikes and you have to reload a bare-iron backup processing facility (or virgin VMs in the cloud) before you can get back into nor- mal business operations. Those CM/CC records give you a known configuration baseline to use to verify that the backup images you loaded are configured, in all details, the way Participate in Change Management 67 your management processes said they should be—the way your live production systems had been configured just before disaster struck. Your organization should start by developing a configuration management plan if it does not have one in operation already. A configuration management (CM) plan defines how an organization will manage the configuration of its hardware and software assets. It defines details such as the roles, responsibilities, policies, and procedures that are appli- cable. A configuration control board (CCB), which ITIL guidance refers to as a change advisory board (CAB), will manage the CM plan. As the CCB is comprised of qualified stakeholders from the organization, they will often be the authors, editors, reviewers, and approvers of the organization’s configuration policies and procedures. They will also be tasked with applying and enforcing the CM plan and helping technical administra- tors adhere to and understand the CM plan. Most importantly, the CCB controls and approves changes throughout the lifecycle of the IT systems, which is why they may also be known as the change control board. Configuration management and change control focus on the life history of individual configuration items and on sets of configuration items. A configuration item (CI) is one discrete part of an IT system, like a piece of hardware or software, that has configurable settings or parameters and should be under formal configuration control. A baseline configuration is a defined, desired set of configurations for a specific CI (or combine mul- tiple CIs into an IT system), which has been formally reviewed and approved. A baseline configuration is valid for a given point in time and may need to be adjusted over time as software or hardware versions change, new vulnerabilities are discovered, or different usage and needs dictate the need for change. When the baseline configuration needs to change, it should be done only through predefined change control procedures. Deciding what a CI should be is a matter of perspective. Consider as an example that a modern platform system such as Microsoft Office Professional might contain between 5,000 to 10,000 individual files, or about 2 GB of code, configuration data, settings, forms, and templates. To the Microsoft Office developer team, each of those files is a CI. To your company’s systems administrators who download licensed distribution kits, configure them, and install them onto dozens or hundreds (or more!) of endpoint systems through- out your company, they may see each new patch version of Office as one CI or see it as thousands of CIs (all those files and all of the patches to them). Fortunately, Microsoft (and many other platform product vendors) provide some pretty extensive maintenance management tools to help you manage their products as deployed systems, rather than as deployed swarms of a huge and unwieldy number of files. Execute Change Management Process As the systems security analyst and administrator, your duties may combine or overlap with those of other systems administrators who actually install, manage, and maintain 68 CHAPTER 1 Security Operations and Administration the operating systems, applications, platforms, web pages, and datasets that make up your organization’s IT architecture. Without their extensive training and significant experience 1 with those products, it’s probably unrealistic for you to try to manage both the security configuration and the product configuration for each installed product. Let’s look at a few Security Operations and Administration of the methods and tools used in establishing and managing both kinds of configurations. Manual configuration is the easiest to understand conceptually—it involves the administrator viewing and changing the configuration settings directly, either by editing a configuration settings data file or by using something like the Windows Registry Editor (regedit). Registry edits (or their equivalents in other operating systems environments) can also be done using batch or script files. Either way, this is a fine-grained, detailed, step-by- step process, which can be useful if you’re stepping through various settings to diagnose a problem or as part of an incremental hardening process. Configuration scanning tools can read the stored data structures used by the operating system and installed programs, extract information from those settings, and in some cases test some of those configuration settings for validity. The resulting list of all of these settings is sometimes called a configuration enumeration. NIST maintains a set of Common Configuration Enumerations that have been associated with security issues that are tracked in the National Vulnerability Database (NVD), and more recent versions of configuration scanning tools can help you detect similarities between a CCE and your system’s current configuration. The CCE database can then provide you with insights and recommendations, drawn from best practices in the field, as to changes you should make in your systems to improve their overall security. In the same breath, NIST and others often provide, specify, or recommend systems hardening information as it pertains to a given configuration enumeration. As a result, some professionals refer to the total bundle (the enumerated configuration and its related hardening information) as an enumeration or as a set of hardening standards for a partic- ular configuration. Since the purpose of having the enumerated configurations in the first place is to collate hardening recommendations with specific configuration items and settings, this is to be expected. If in doubt as to what is meant or included, ask for clarification. Another useful tool is a configuration change detection tool. It is different than a configuration scanner tool in that instead of asking the IT asset “Are you configured correctly?” it asks, “Did your configuration change?” It takes a snapshot of a given sys- tem’s configurations, presumably after it was configured correctly and securely. Then, if any of the configurations are changed, it sends an alert to one or more relevant security stakeholders. Vendors are adding additional features and capabilities to both scanner tools and change detection tools, blurring the line between the two. Some tools now do both. Participate in Change Management 69 When you want to control how your security tools share data, you can use the Secu- rity Content Automation Protocol (SCAP). SCAP is a way for security tools to share data. It is an XML-based protocol that has many subcomponents called specifications, includ- ing one for CCE. It is a taxonomy for describing configuration requirements, which is essential because of the sheer number of configurations and their nuanced differences. CCEs are written for, and are grouped by, specific IT products or technology types. The vulnerability equivalent to CCE is the Common Vulnerabilities and Exposures (CVE). CVE is more widely adopted than CCE because the vulnerability scanner market is larger and more mature than the configuration scanner market. In fact, some major vulnerability scanning tool vendors have added CCE (configuration) scan- ning to their traditional CVE (vulnerability) capabilities. Learn more about CCEs at https://nvd.nist.gov/config/cce/index. In addition to other standards and guides, vendors (especially OS vendors) typically publish secure build outlines for their own products and often make tools available for provisioning and monitoring configurations. Identify Security Impact Any proposed change, even applying a patch kit or bug fix to alleviate a security prob- lem, may inadvertently introduce a new vulnerability or a new risk into your systems and your business operations. Change packages should be examined to identify any potential changes to your operational procedures for getting work done with the affected systems and assets. Descriptions of the changes, and in particular the issues or vulnerabilities that are acknowledged as not addressed in the patch or update kit, should also be closely looked at to see if they suggest possible new areas of risks to your operations. If it’s prac- tical for you to delay installing the update until other organizations have installed it and operated on it for a short while, you may want to consider this—but only if you have an alternative way to protect your system from exploits targeted at the vulnerabilities the patch or update is going to remediate! When analysis fails to surface anything to help alleviate your fears of causing more trouble and risk with an update than the fix is trying to eliminate, it may be time for some security-driven testing. Testing/Implementing Patches, Fixes, and Updates Chapter 7 goes into more detail on the overall software development process and the concepts behind the software development lifecycle (SDLC) models, both classic and cutting-edge, that are in widespread use today. As the security administrator or team member, you may need to be involved in the overall development process to ensure that any security-relevant issues, perspectives, functional requirements, and insights get incor- porated into both the product as it is developed and the management process that keeps 70 CHAPTER 1 Security Operations and Administration that development on track. At some of those test opportunities—which there are more of in a large systems development than there would be for a small, tightly focused patch or 1 update—security may need to be more of an active member of the test team and not just an interested stakeholder and observer. Your experience and insight about what happens Security Operations and Administration when systems fail to be secure can be of great help to test teams as they conduct scenario- based test cases; your knowledge of how the application or system under test should be interacting with network and systems security monitoring and incident detection tools may also benefit the post-test analysis activities as well. It is best and common practice to do security-related testing in an isolated testing environment, safely quarantined off from your live production environments. Virtual machines in tightly secured test and development subnets, and hosts are ideal for this. This contains any problems that the test may otherwise set loose into your production systems or out into the wild. It also allows you to be more aggressive in stressing the sys- tem under test than you could otherwise afford to be if testing were conducted on or asso- ciated with your live production environment. You can also adapt penetration testing scenarios and approaches you would otherwise use against your systems hosted in an isolated testing environment, before you’ve released those new versions of the systems into live production and operational use. Black box, white box, or other forms of penetration testing may be quite useful, depending upon the nature of the changes you’re trying to evaluate. PARTICIPATE IN SECURITY AWARENESS AND TRAINING In many respects, you, as the on-scene security professional, have the opportunity to influ- ence one of the most critical choices facing your organization, and every organization. Are the people in that organization the strongest element in the defense, security, safety, and resiliency of their information systems, or are these same end users, builders, and maintainers of those systems the weakest link in that defense? This is not an issue of fact; it is a matter of choice. It is a matter of opinion. Shape that opinion. Awareness is where you start shaping opinion, and in doing so, you inspire action— action to learn, action to become, action to change the way tasks get done and problems get set right. You might not be a trained and experienced educator, trainer, or developer of learning paths, course materials, and the tactics to engage your co-workers in making such an awareness campaign succeed. Don’t worry about that. What you can and should do, as part of your professional due care and due diligence responsibilities, is engage with management and leadership at multiple levels to obtain their support and energy in mov- ing in the right direction. Participate in Security Awareness and Training 71 Increasing your co-workers’ awareness of information security needs, issues, and opportunities is the first step. They’ll then need a combination of the conceptual knowl- edge and the practical skills to translate that awareness into empowerment, and empow- erment into action. Depending upon the lines of business your organization is involved in and the marketplaces or jurisdictions it operates in, there may be any number of risk management frameworks, information security policies and standards, or legal and regu- latory requirements regarding effective security awareness, education, and training of your organization’s workforce that must be complied with. This is not a cost or a burden; this is an opportunity for small, focused investments of effort to turn the tables on the threat actors and thereby take a significant bite out of the losses that might otherwise put your team out of work and the organization out of business. Security Awareness Overview It’s easy to see that in almost every organization, no matter how large or small its work- force, no one single person can possess the knowledge, skills, abilities, and attitudes to successfully do all of the jobs that make that organization successful. By the same token, no one information security professional can keep all of the systems and elements of the IT architecture secure and plan, develop, and teach the security awareness, education, and training programs the rest of the workforce needs. What any of us can do—what you can do—is to take a thumbnail sketch of what such programs need to achieve, share this with management and leadership, and assist where you can with the expertise and talent you do have to make that sketch of a plan become reality. Let me offer you some thoughts about this, from my experiences as an educator, trainer, and information secu- rity professional. Let’s start with awareness—the informed recognition that a set of topics, ideas, and issues exists and is important. Awareness shines a different light on the day-to-day, triggering moments of recognition. Awareness shatters the false myths, the explana- tions that everybody “knows” but have never tested for validity. Simple but compelling examples can do this; even something as simple as “fake phishing” attack emails that you send to your own workforce can, over time, increase the percentage of that work- force that get better at spotting a possible attack and dealing with it immediately and correctly. Education explains concepts and links them to awareness. Education can be formal, focused around an identified body of content or aimed at the student attaining a cre- dential of some kind attesting to their accomplishment. Informal education can be just as effective and often is well suited to rapidly evolving situations. Education stimulates thinking and creativity. A short course in root cause analysis can start with getting students to recognize the power of simple, open-ended questions. 72 CHAPTER 1 Security Operations and Administration Training teaches skills and guides learners in becoming increasingly proficient in applying them to realistic situations. Training activities that use “spotters’ guides,” for 1 example, can demonstrate packet sniffing and filtering or anti-phishing email screening techniques and then use checklist approaches as the frameworks of labs and exercises to Security Operations and Administration enhance learners’ abilities to recognize concepts in action and make informed decisions regarding actions to take. Competency as the Criterion It’s well worth the investment of time and thought to create a short list of the key infor- mation security competencies that different subgroups of your workforce need, if they are going to be able to make real contributions to improving information security for the team as a whole. The larger your organization and the more diverse the individual work- groups are in terms of tasks, context, and the sensitivities of the information they work with, the greater the likelihood that you’ll need numerous short lists of such competen- cies. This is okay; make this manageable by starting with the groups that seem to need even a small step-change in security effectiveness and work with them to identify these core competencies. By the way, some education and training program professionals will refer to this core competencies approach as a needs assessment. The name does not matter; the results do. Both should produce as an outcome a list of tangible, clear statements of what learners need to learn and the standards by which they must be assessed to demonstrate the suc- cess of that learning. It’s likely that your company or organization has trainers and human resources devel- oper talent within the HR or personnel department. Find them; get them involved. Get their help in translating these first few sets of core competencies into the next layer of detail: the activities that learners have to perform well at to demonstrate that they’ve successfully learned that competency to the required degree of rigor. Get them to help you find teaching and learning assets and materials that the company already has; or, get them to help you find other assets. Reuse what you can find, learning from how well it works, before spending the time to develop something custom-made for your situations, people, mission, and needs. Build a Security Culture, One Awareness Step at a Time You’ve successfully engaged others in the company to take on the tasks of selecting or developing the teaching and learning assets, structuring the courses, and finding the right people to act as trainers and teachers. You’ve got them managing the identification of which employees need what levels of learning, how often they need it, and when they need to get the learning accomplished. As the on-shift or day staff security administrator, that’s a great segregation of duties to achieve! Now what? Participate in Security Awareness and Training 73 Walk the hallways of the company’s campus or locations; keep your eyes and ears open for signs that awareness, learning, and skills-building are happening. Look for signs of trouble that suggest it isn’t working fast enough or well enough. Step into those situations informally and casually, and lead by example and inspire by action and word. Suggest to people in these problematic contexts, be they workers, supervisors, or mid-level managers, that they’ve got the opportunity to empower themselves, and you can help them. Too many organizations fall into the administratively simple task of regularly schedul- ing repetitive training activities. These could be messaging opportunities that strengthen each worker’s future with the company by enhancing the organization’s survival and suc- cess. Instead, they oftentimes turn them into tick-the-box, square-filling exercises in futil- ity. If this is happening in your organization, shine some light on it; help others become aware of the need to turn that messaging around. Quickly. PARTICIPATE IN PHYSICAL SECURITY OPERATIONS Information security specialists, such as SSCPs, need to be aware of all threats to the information systems in their care and be able to assist, advise, and take action as required across many functional areas in their organization. If your company is truly cloud-based, with no data center of its own, you’ve still got threats in the physical domain to contend with. Remember, too, that your attacker could turn out to be an insider who turns against your team for any number of political, financial, emotional, or personal reasons. Physical Access Control If the attackers can get to your systems, they’ve got a chance to be able to get into them. This starts in the physical domain, where access includes physical contact at Layer 1 net- work systems, at the USB ports or memory card slots on your endpoints and other devices. It includes being able to see the blinking LEDs on routers (which blink with each 1 or 0 being sent down the wire), and it includes being bold as brass and just walking into your office spaces as if they’re a pizza delivery person or business visitor. And although we’ve not yet seen it reported, it won’t be long now before we do see an attacker using hobby- ist-grade UAVs to carry out intrusion attempts. Chapter 2 will look at the concept of defense in depth, integrating a variety of deter- rence, prevention, and detection capabilities to defend the points of entry into your systems. Threat modeling, done during the risk assessment and vulnerability assessment phases (which Chapter 3 examines in more detail), have given you maps of your systems architecture, which show it at the data, control, and management planes as well as in the physical dimension. Start at the outermost perimeter in those four planes and put on your penetration-tester hat to see these control concepts in action. 74 CHAPTER 1 Security Operations and Administration One major caution: What you are about to do is tantamount to penetration testing, and to keep that testing ethical, you need to first make sure that you’re on the right side 1 of law and ethics. Before you take any action that might be construed as an attempted penetration of an organization’s information systems or properties under their control, Security Operations and Administration gain their owners and senior managers permission in writing. Lay out a detailed plan of what you are going to attempt to do, why you propose it as worthwhile, and what you anticipate the disruptions to normal business operations might be. Work with them to specify how you’ll monitor and control the penetration test activities and how you’ll sus- pend or terminate them immediately if required. As you learn with each step, err on the side of caution and go back to that management team and ask for their written permis- sion to take the next step. At a minimum, this will keep you out of jail. It will enhance your chances of staying employed. It will also go a long way toward increasing the awareness of the threat and the opportunity that your management and leadership stakeholders have to do something about it. ✔✔ Don’t Fail to Imagine The vast majority of businesses and nonprofit organizations have almost nothing to do with national defense or with international intrigue; their leaders, managers, and owners see themselves as light years away from international terrorist plots or organized crime. And they probably are. Unfortunately, this distance can bring a false sense of security with it, one that turns off their imagination. In virtually every cyber attack, the target is the data that the organization holds. Data about their employees, their customers, or their suppliers; or transaction histories with their partners and their banks. Attackers may have far more reasons for finding value in your data than you think. Without your data, you can’t operate. With your data, your attackers can gain in ways you don’t have to imagine in order to stop cybercrime in its tracks. Property Approach From early reconnaissance and target selection onward, an APT actor will need to see, sense, observe, and probe at your facilities, your people, and your IT systems. You need to balance allowing these contacts for legitimate outsiders while not making it too easy for Participate in Physical Security Operations 75 a hostile agent to learn too much. You don’t control the Internet any more than you con- trol the physical spaces outside of the property line around the buildings your company occupies, but you can and should consider what you choose to make visible, audible, or otherwise physically observable, for example, via: Visual line of sight, depending on the sensitivity of the organization’s operations. Line of sight might be obscured by limiting windows in construction, covering windows in sensitive areas, obstructing views with landscaping/formation, or other means. Vehicular approach, including roads and driveways toward the property/facilities. For secure facilities, these should deter a straight approach to disallow a drive to build up excessive speed and should include obstacles with bollards, barriers, or retractable tire spikes. Movement patterns of your workforce can reveal when they’re working a special, important activity that demands a surge of effort, versus a normal routine pattern of arrivals and departures. In the digital domain, use periodic black-box ethical penetration testing techniques to examine all publicly-facing information that your organization makes available on web pages, via e-commerce or e-business connections, and even in advertising and print media. Port scanning and network mapping also may show you spots where your systems reveal too much about themselves. Perimeter At the outer boundary of the property, security controls can be implemented for access control. Fences/walls: While generally seen as deterrent or preventive controls, fences and walls can also be combined with additional mechanisms to offer detection capabilities. Cameras: Cameras serve a deterrent purpose but can be combined with moni- toring capabilities (such as guards watching a video feed or motion sensors) for detection functions. Know that it’s fairly easy for dedicated attackers to separate the cameras that are actually monitored from those that are “perimeter dressing” and most often ignored. Buried lines: While these serve no deterrent function, underground sensors can be used for intrusion detection within the border of a property. Access control points: Guard stations or gates can be staffed or equipped with additional mechanisms (card readers, cameras, turnstiles, etc.). 76 CHAPTER 1 Security Operations and Administration Patrols: Guards (human or canine) can provide deterrent, detective, corrective, and recovery controls. 1 Motion sensors: There are a variety of technologies that support the organiza- Security Operations and Administration tion’s ability to surveil the perimeter and any area outside facilities, including the cameras and buried lines, as well as microwave, laser, acoustic, and infrared systems. Lighting: Well-lit areas serve both deterrent and detective purposes. Continual maintenance of all lighting sources is crucial, as a burned-out or broken bulb can defeat any security benefit the light might provide. Parking The most dangerous workplace location is the site where vehicles and pedestrians meet. It is imperative to include sufficient lighting, signage, and conditions (width of right-of- way, crosswalks, etc.) to minimize the possibility of threats to human health and safety. Monitoring is also useful, as parking areas are often locations that are accessible to the public and have been frequently used to stage criminal activity (workplace violence, rob- bery, rape, murder, etc.). If the parking structure allows for entry to the facility, this entry should be equipped with access controls, and all entryways should feed to a single reception point within the facility. Generators and fuel storage, as well as utility access (power lines, water/sewer pipes, etc.), should be protected from vehicular traffic, either with distance or with additional physical obstructions. There must be sufficient access for fuel delivery traffic, but this should be severely limited to reduce risk. Facility Entrance In addition to the other entrance controls already mentioned, the entry to the facility might include the following: Reception staff: This includes guards or administrative personnel who observe people entering and leaving the facility. Logging: This may be as technologically rudimentary as a sign-in book or com- bined with sophisticated badging/monitoring capabilities. Flow control: Turnstiles or other mechanisms ensure only one person at a time can pass, typically only after presenting a credential (such as a badge or biometric element). Participate in Physical Security Operations 77 Internal Access Controls In addition to the other access control elements used for maintaining physical control of the workplace environment listed elsewhere in the book, the security practitioner should be familiar with the following: Safes: Secure containers that can offer protection from unauthorized access, fire, water damage, and, in some cases, chemical contaminants. Both the safe itself and the lock on the safe should be rated by a standards body for specific criteria, according to the particular needs of the organization. Secure pro

Chapter 2: Access Controls PDF

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue