Security Practices
This is a guide on security practices.
Check out Audible on Amazon and listen to the newest books!
Configuration Management
Configuration management encompasses all the components that must be changed or managed in order to deliver a product or service. This discipline is frequently referred to as service configuration management, and its primary purpose is to ensure that accurate and reliable metadata and information exist regarding the configuration of services and configuration items. Configuration management can involve a variety of documentation tools, including diagrams and topologies. Platforms such as Lucidchart offer a wide range of templates that can be utilized throughout the lifecycle of configuration management activities.
Establishing baselines is an essential aspect of configuration management because change management depends upon these configuration management baselines. To achieve continual improvement of the configuration management database, it is necessary to establish a baseline so that proper change management and patch management can be performed. In addition to diagrams and topologies, configuration schemas—such as database schemas—are often part of the configuration management process.
Asset labeling and tagging should follow an established schema and naming convention. The naming and tagging can be either physical, such as a physical label attached to a laptop, or logical, such as tags or metadata stored within a database. Configuration management serves as the foundation from which change management emerges.
Change Management
Change management, also known as the change control practice, has the goal of maximizing the number of successful service and product changes. It is essential to ensure that risks have been adequately assessed, authorized, and managed through the use of a change schedule. Change management often involves some type of log, ledger, register, or database. In many cases, organizations utilize document databases or key-value databases, such as Amazon Web Services DynamoDB.
The change management lifecycle consists of six phases: submitting, approving, documenting, testing, implementing, and reporting. During the submitting phase, the proposed change is analyzed and validated. If necessary, the submitter may be required to provide additional information before the change is approved, or the request may be escalated to a higher authority, such as a change advisory board. In the approving phase, the proposed change request should first be delivered to the individual or group responsible for change management within the organization. This might be a service desk, a steering committee, or members of executive management, often referred to as the C-suite.
The third phase is documenting. After approval, the change must be entered into a change log or configuration management database (CMDB). This log or database must be updated regularly as each change progresses through the various phases. It is important to note that documentation is typically performed at every stage of the change management lifecycle. Testing occurs before implementing the change, and there may need to be a formal testing verification process. This typically does not happen for a standard or normal change, but for a major change, modifications may need to be allowed if challenges or issues arise. During the testing phase, a determination can also be made regarding whether any other processes or people are affected by the change.
The fifth phase is implementing. After the change has been tested and approved, it can be deployed based on a predetermined schedule. The schedule needs to document the projected phases of the change and define the milestones for the change process if necessary. It is also important to recognize that the change could be automated rather than manual. In such cases, a large number of automated changes should be part of an orchestration, software, or implementation effort. The sixth phase is reporting. After the change has been implemented, a full report should be submitted to management. If there are any negative consequences resulting from the implementation of the change, this should trigger an iterative move to an earlier phase of the lifecycle.
In summary, configuration management comes before change management, and the change management lifecycle consists of six phases: submitting, approving, documenting, testing, implementing, and reporting, with documentation occurring throughout the lifecycle and the potential for iterative moves backward to a previous phase if necessary.
Data Sovereignty
Data sovereignty involves considerations such as differences between Asian and European customs. During the Cold War, the United States and other governments generated intricate regulations that controlled the export of sensitive hardware and software products between nations. These regulations included the control of transborder data flow of new technologies, intellectual property, and personally identifiable information such as credit card information. The International Traffic in Arms Regulations (ITAR) controls the export of items that are specifically designated as military and defense items. This may apply to an organization depending upon its specific value proposition. The Export Administration Regulations (EAR) cover a broader set of items designed for commercial use but which could have military applications. For example, EAR has an entire category that covers information security products.
Cloud computing geolocation is another important consideration. According to NIST, shared cloud computing workloads can move from cloud servers located in one country to servers located in another country. Each country has its own laws for data security, privacy, and other aspects of information technology. Because the requirements of these laws may conflict with an organization's policies or mandates, an organization may decide that it needs to restrict which cloud servers it uses based on their location. A common desire is to only use cloud servers physically located within the same country as the organization or physically located in the same country as the origin of the information. Geolocation can be accomplished in many ways with varying degrees of accuracy, but traditional geolocation methods are not secured and are enforced through management and operational controls that cannot be automated and scaled. Therefore, traditional geolocation methods cannot be trusted to meet cloud security needs.
Data Protection
Different security controls are used for data at rest or data storage. Examples include file encryption, full disk encryption, encrypting snapshots of virtual drives and volumes, and encryption of object storage, such as in SharePoint or cloud storage. Security controls for data in transit or data in motion include variants of IPSec Authentication Header or Encapsulating Security Payload (ESP). For most users, Transport Layer Security (TLS) 1.2 or higher is used for HTTPS traffic. Protecting data in memory or data in processing may involve newer technologies and is often more optional.
It is also necessary to consider the protection of data on mobile devices and IoT devices, particularly as these devices are tokenized for payments, multifactor authentication, and a wide variety of IoT uses. Tokenization can lead to data loss or data leakage. Mobility solutions are covered in a dedicated lesson in Course 15, which addresses Enterprise Mobility Management (EMM), a combination of mobile application management and mobile device management.
Data loss prevention (DLP) is a critical and emerging initiative in organizations. DLP involves managing the loss and leakage of valuable and critical data beyond an established security domain. This could occur within email systems, local storage, cloud storage, or mobile devices. The data at risk includes intellectual property such as corporate secrets, formulas, future marketing campaigns, upcoming mergers or acquisitions, personally identifiable information, personal health information, and customer data such as credit card information. DLP may involve masking or stripping out certain information, similar to redaction, and using strong encryption. Tools are available to perform these functions.
Data can leak through email, messaging, social media posting, bit torrent, and cloud storage. Leakage can occur to outsiders, competitors, regulators, unauthorized internal users, external users, the press, or the media. The results can include varying degrees of primary and secondary loss, such as company defamation, monetary expense from lost records, legal liabilities, loss of assets, breach of goodwill or customer trust, increased borrowing costs, incident response costs that divert personnel from their main activities, and possibly business closure if the breach is serious enough.
Some organizations, as part of their DLP efforts, become involved with digital rights management (DRM). This is common among companies that produce content such as movies, music videos, and music files. DRM mechanisms are varied access control technologies used to control the usage of proprietary hardware and copyrighted works. Companies deploy systems within devices to enforce their DRM policies. DRM technologies attempt to manage the use, modification, and distribution of copyrighted software and multimedia content. These systems are found in smart televisions, CD players, DVD players, TiVo boxes, and set-top boxes from broadband providers, as well as consumer items purchased from retailers.
Hardware Security Modules
A hardware security module (HSM) is typically used for managing, processing, generating, and storing keys. These keys are used for public key infrastructure, private keys, Secure Shell, and cryptographic material for trusted platforms. An HSM can also verify digital certificates and digital signatures, encrypt and decrypt sensitive data, and verify the integrity of stored data, such as hashes that support a web service or single sign-on for a directory service. Companies such as Gemalto offer dedicated appliances, but an HSM can also be a module in a PC, a rackmount server, or, at cloud service providers, a virtualized abstraction offered as Cloud HSM. HSMs also provide SSL acceleration to offload public-key SSL/TLS processing. Cryptocurrency exchanges such as Coinbase or Kraken could use HSMs to store client blockchain data in an immutable fashion. Foundations of a trusted execution environment (TEE) or trusted computing (TC) use these dedicated crypto processors as part of a trusted model.
Geographical Considerations
Offsite data and backups should be geographically farther away than across the street. Considerations include the distance within the same city, the same state, the same country, or the same cloud. Cloud providers, in their availability zones, ensure that data centers are not too close together. They are really part of a metropolitan area network with high-speed connectivity. Another aspect of cloud service providers relates to the hardware security module discussed previously. Even though Cloud HSM is available, it may not be usable because of regulations or governance. Some accreditation and certification bodies demand that the physical HSM be onsite. Auditors may not allow the use of Cloud HSM. Cloud providers are working vigorously to make their abstracted hardware security modules industry compliant.
Different types of disaster recovery sites include cold sites, warm sites, hot sites, and mobile sites. These tie into where offsite data and backups are stored as part of business continuity planning. Wherever data and backups are located, it is important to consider whether operations can be conducted there, whether they can be stored there permanently, what security standards and practices are in place, whether CIS (Center for Internet Security) or other best practices are being implemented, and what the legal implications and laws are in that particular area. Privacy laws must be known. For the European Union, the GDPR applies. For healthcare and the medical field, HIPAA or HITECH privacy and security regulations apply. If a company engages in import and export, restrictions on importing or exporting technology and cryptographic modules must be understood. As mentioned in Lesson 3, ITAR controls and EAR apply. In the United States, the website for the U.S. Commerce Department also provides information.
Cloud Access Security Brokers
Cloud Access Security Brokers (CASBs) are relevant for services such as Salesforce, Workday, Zoho, or Office 365. A CASB can be on-premise, serving as a consultancy, or it can be an in-service provider cloud. CASBs act as a gatekeeper to help enforce enterprise security policies while cloud resources are being accessed. Cloud access security brokers can help extend the organization's policies beyond the local infrastructure. They can provide visibility, compliance, data security, and threat protection. They can assist with the implementation and enforcement of identity and access management, as well as single sign-on services, such as federated access with web service sign-on and implementation of SAML 2.0, OAUTH, OIDC, and Active Directory integration, among others.
Response and Recovery Controls
Response and recovery controls involve implementing safeguards that will eliminate or reduce risk exposure. Risk may still exist, which is known as residual risk, but the impact will be reduced. Risk transfer or risk sharing involves passing the risk to a third party, such as an insurance plan or a cloud service provider. Risk avoidance means deciding not to undertake any actions that introduce risk.
Security guards typically operate 24x7, but this varies per organization. Security guards fulfill several different types of controls. Their mere presence can be a deterrent, but they can also be a detective control and a preventative control. Security guards and teams should provide rapid security response if an intrusion or an incident occurs. Considerations for security guards include whether to hire them directly or contract with a company, whether they will be certified or licensed, whether they will be armed or unarmed, whether there is a screening process and who performs the screening (in-house or third party), who trains the security guards and how ongoing training is handled, and the impact on insurance. Having a security guard can lower insurance premiums, but having armed guards could add expense because of possible liability.
Another important response and recovery control is the incident response team, or Computer Security Incident Response Team (CSIRT). This could be an internal team that is dedicated, a swarm team of certain key individuals in different departments who swarm as needed, or a third-party IRT. The IRT provides 24x7 Internet response service to users, companies, government agencies, and organizations. The IRT should deliver a reliable and trusted single point of contact for reporting computer security incidents. They should provide the means for reporting incidents and for disseminating important Internet-related information not only to stakeholders but also to key C-suite members. CSIRT will often be the first responder in many scenarios and can also be involved in cyber forensics.
SSL/TLS Inspection
SSL/TLS, which stands for Secure Sockets Layering and Transport Layer Security, with TLS 1.2 and 1.3 being the most common versions, provides the most common ways to protect data in transit on public web servers and at cloud service providers. SSL/TLS inspection involves hardening all web services that respond to HTTPS as clients on the Internet and even in private networks. It also comprises the deployment of Web Application Firewalls (WAF) and deep packet inspection at site perimeters and on cloud computing components such as elastic load balancers, content distribution network gateways, and application programming interface gateways to decrypt and inspect TLS traffic. Managed Security Service Providers (MSSPs) can offer cloud-based inspection and analysis solutions for a price.
Best practices when deploying TLS on web servers include keeping security software and settings up to date, ensuring browsers are updated and controlling which browsers can connect to web servers, not allowing vendor-installed code to intercept traffic, ensuring client computers are malware-free, performing certificate revocation checks specifically with OCSP, verifying that encryption is being performed and that the most secure security suites are being used, checking certificate expiration dates in the public key infrastructure, obtaining TLS certificates only from trusted authorities (certificate pinning), performing OCSP stapling by forcing the revocation check against a server, and deploying HSTS protocols on the server side to force web clients and browsers to perform secure activities.
Hashing and API Considerations
Cryptographic hashes are only half the key strength due to the birthday paradox. For example, if cryptographic hashing is used on passwords in a back-end web database using SHA-128, the actual strength of the algorithm is only half that. The birthday paradox states that if twenty-three people are gathered together, there is a 50 percent probability that two of them share the same birthday, not birth date, but birthday. Older protocols such as MD5 and SHA-1 should be avoided due to collision attacks. In newer implementations, if the capability exists, consider using security suites that use elliptic curve Diffie-Hellman, as opposed to the modular clock math of the original Diffie-Hellman, and employ forward secrecy, which means using a key that is derived from another key instead of the original key. AES-256 Galois Counter Mode (GCM) is the preferred method and has built-in hash authentication and integrity with its symmetric encryption, known as an AEAD.
Five considerations for application programming interfaces (APIs) are as follows. First, digitally sign all API calls within organizations to partner sites over the WAN or MAN and for programmatic access to any resources at a cloud provider. Second, do not embed credentials such as usernames and passwords into an API call. The same applies to cryptographic keys. The keys used to secure API calls should be ephemeral, meaning they are used for the lifetime of the session and then destroyed. Third, only connect to trusted sources, such as cloud providers where there is a shared responsibility agreement and service level agreements. Fourth, recognize that the usage of IPSec on the Internet may be mandated based on compliance or regulations. Any secret keys used for API calls must be protected on the client workstation or management station. Fifth, ensure that developers and programmers who are making API calls, whether through REST API queries, software development kits (SDKs), or command line interfaces, are using secure coding practices throughout the entire lifecycle.
Site Resiliency
Site resiliency is the capability of a server, network, database, or storage system to rapidly recover and continue operations when a hardware failure, power outage, or other disruption occurs. The more common term is site resilience, which refers to maintaining the durability and high availability of mission-critical services and data. Most organizations include some option for site resiliency in their disaster recovery plans.
A cold site is basically an empty building that has HVAC capacity and power, and possibly a wired Ethernet network throughout, but that is about it. In the case of a disaster or event, everything must be moved to the cold site, and it could take at least 24 hours or more to get operations up and running. Often a cold site will not even have wired Ethernet but depends upon a temporary wireless local area network for the duration of the event.
A warm site has more capabilities. It includes the things mentioned for a cold site, but also has some hardware, possibly racks to hold servers, switches, and routers, and racks to support RAID arrays. It will most likely have wired Ethernet. It may be running with power and HVAC at a low level on an ongoing basis. There may even be some personnel managing it off and on over the course of a year.
A hot site is like a parallel site. It may not be running exactly in parallel with the operation or facility, but there is enough duplicate hardware and software that it will take an hour or so to get up and running. This is the most expensive option and one that most organizations will not choose. It is also called a mirrored or parallel site.
Some companies use large trailers and mobile site solutions. Organizations may rely on a mobile site in the event of an emergency or disaster. Some organizations take advantage of a hybrid cloud solution where they have redundancy, with other onsite data and systems at a cloud provider such as Google Cloud Platform or Microsoft Azure, taking advantage of high availability zones and regions all over the world.
Honeypots
Honeypots and evil twins can be on wired networks or wireless networks, with evil twins more likely in a wireless network. They are used to trap potential attackers and as a man-in-the-middle attack. Honeypots are often built with virtualization technology, with Linux and Windows operating systems running in a hypervisor. They should be semi-hardened, not wide open where it is obvious that it is a honeypot, but just difficult enough for someone with beyond script kiddie capabilities to breach or exploit the system. The company then determines how to react.
The organization may go as far as building an entire network that represents a honeynet, an entire physical but more likely virtual subnet used to entice attackers for gathering intelligence and counterattacking. This might be an evil twin to the DMZ or public access zone. This entire network can also be created in a virtual environment.
Honeyfiles are a type of honey token most often used to catch privileged insiders during a structured attack or data breach. If the privileged insider executes the file or acts on the file, or a token such as an access key to Amazon Web Services, then the internal security team, HR, and Legal can take action against the privileged insider. Regardless of the method used—honeypots, honeynets, honeyfiles, or honey tokens—these are all often part of active defense. Once information is gathered and the attacker is trapped, this can be used as a deception mechanism to gather information. Organizations may go further into attribution, trying to find out who the adversary is and potentially the country and location, because the third type of defense is attack back or counterattack. Some larger organizations have red teams that will counterattack or attack back, and government agencies or the military definitely do. Legal ramifications to counterattacking must be considered.
Deception has become a strategic tool used by many large organizations from several sectors. Fake telemetry involves augmenting existing tools in the enterprise to offer critical threat intelligence for early breach detection and high-fidelity alerting and visibility. Fake telemetry may involve adding a fake layer to the infrastructure by employing decoy or trap assets, tar pits that slow down attackers and get them bogged down, fake data, and other artifacts in the current environment. No system or person should ever have access to the fake unless actively seeking something or there is a misconfiguration.
A specific type of fake telemetry is a DNS sinkhole. Using DNS sinkholes, threat analysts can look at malicious traffic in real time, monitor and analyze it, and then generate better prevention controls in the future. An example is the Botnet Filtering feature on a Cisco Adaptive Security Appliance firewall. The attacker sends malicious email over the Internet. The organization computer receives the email with the malicious site link. The organizational system then makes a query to a DNS server. The DNS server fetches the malware from a malicious server on the Internet. However, it will then route traffic of malicious sites or bad reputation sites to an IDS sinkhole server and intrusion detection for learning to management stations in the management VLAN before it ever gets back to the organizational computer.