Security Operations
This is a guide on security operations.
Security Principles for Operations
Let's look at some security principles, principles for operations. And a lot of these principles are closely related to networking, but they can all apply to all different aspects of IT operations.
The first, of course, is least privilege. Which basically means that entities should be given only the rights and privileges necessary to fulfill their assigned roles and responsibilities. If they need escalated or elevated privileges, it should be done through a change in configuration management system. It should be a ticket that they go through, a trouble ticket or a service desk implementation, and only on an ad hoc basis. These privileges have preventative control that should apply everywhere, not just to files on a file server. [Video description begins] With least privilege, what they don't know won't hurt them or the company. [Video description ends]
Rotation of duties basically involves having employees periodically swap roles or swap their tasks. Maybe on a quarterly basis, maybe on an annual basis. You could also include with rotation of duties mandatory vacations and mandatory leave. Okay, so if someone has four weeks of vacation, they have to take that vacation and actually leave the facility for a week or so. So then their replacement comes in, the temporary replacement. And then we're able to detect any irregular activities like fraud, any data breach, theft, embezzlement. Any other illegal or anti-policy activities while that person is either rotated out of the position or they're on their mandatory vacation.
Separation of duties means involving two or more individuals to manage a system or to handle a task or a job. It often takes two or more people to commit a crime. Okay, there needs to be some collusion. And we're saying here that one person is not going to have complete control or management of a process or a procedure. By separating duties, for example, one particular person can back up to the cloud, another can restore from the cloud. It reduces the opportunity for fraudulent activities. It also provides visibility and oversight. Separation of duties can also be a dual operator environment. So, for example, any check, expense check that's written from the comptroller or the finance department for over $1,000 has to have at least two signatures. [Video description begins] A diagram illustrates an example of four phases in a process. In the example, Scott is responsible for the Development phase; Keith is responsible for the Prototype phase; Dorothy is responsible for the Design phase, and George is responsible for the Testing phase. [Video description ends]
Defense in depth involves a wide variety of tasks, okay? This is layers of security like we see here in our castle. You're going to create security zones or security domains. And then between those zones or domains you're going to have zone interface points, which are typically firewall...next generation firewall and IPS services. You will whitelist your traffic going into the zones with multiple redundant systems. You're providing layered security controls from OSI layer 2, the data link layer, all the way up to the application layer 7. And so think of defense in depth like you would do in the military to defend a castle. Or to defend a beachhead, for example, with mines starting out in the harbor, and then different things on the beach to prevent those tanks and those infantry troops from making their way back to the secure area.
Because of mobile devices and mobility and virtualization, compartmentalization has become a very key aspect of security principles. This can be done logically, okay? You can compartmentalize private VLANs, [Video description begins] The abbreviation for private VLANS is PVLANS. [Video description ends] for example, creating logical VLANs within a VLAN, still in the same IP subnet; or you can do it physically on the device ports itself or multiple devices. It's common to create zones or compartments using virtualization. Tools like Dockers and Kubernetes can be used for contained apps and applications running specifically at cloud service providers. Look at the iPhone, secure enclave. If you do a little research on that, you can see how the iTouch functionality is running in its separate own enclave operating system on the mobile phone. Also, along with compartmentalization comes sandboxing, which you might create a sandbox environment in a private data center, or in a private virtual cloud where you can run malware exploits and test your security systems. It could also involve using trusted systems like SELinux.
An example of this would be software defined networking, or SDN, where literally the routers, and the switches, and the firewalls, and the sensors are all running in virtual machines. You also have a separation of management, control, and data traffic in these virtual machines with a controller handling all of the difference software. There'll be communication through an application programming interface between the controllers and the network devices which are virtualized, the applications and the controllers. Admins will also be using logical access to all the components. And it's easy to have redundancy, because we're running in a virtual environment, VMware or vSphere. If you're going to deploy a SDN as kind of a compartmentalized solution, some security considerations: Make sure that you clearly define the trust boundaries. Ensure that there's strict role based access controls. Use only proven protocols and methodologies. [Video description begins] Open standards. [Video description ends] Evaluate on a regular basis your CIA controls and secure all communications. [Video description begins] CIA in this instance refers to confidentiality, integrity, and availability. [Video description ends] You want to have secure key management, least privilege principle, a deny all by default. And make sure you have accountability and traceability and visibility mechanisms in place in your SDN environment.
Another security principle is mediated access, or using proxies for authentication proxy. And this can be authenticating packet mode, which is, you know, a web server being accessed from a browser through a proxy. Or character mode, which is administrative or managerial access to a device. You can have encryption and decryption proxies, SSL accelerators, Translation proxies that translate network and port address translation, or XML servers or business tier, Middle tier logic servers doing translation, for example, in a healthcare coding environment. You can have a client server proxy, and it can be active or passive. In other words, the client or the device trying to get access to the server can be going through a proxy. And the proxy could be providing up some kind of captive portal or some web page. Or it could be done as a proxy and it's done passively where the client doesn't even really know it's going through a proxy. They can do URL filtering. They can do content filtering, like a web application firewall. [Video description begins] The abbreviation for web application firewall is WAF. [Video description ends] It could be a email proxy, like a message transfer agent proxy, [Video description begins] The abbreviation for message transfer agent is MTA. [Video description ends] like the Cisco Email Security Appliance. [Video description begins] The abbreviation for email security appliance is ESA. [Video description ends]
Or it can be the point of contact for management into other private zones or compartments by coming through a bastion host or a jump host to get access to front-end, back-end servers, and databases. Visibility and accounting, also extremely important principle, using AAA, RADIUS and DIAMETER and TACACS+ accounting, system logs, SNMP version 2C and version 3. NetFlow collectors using version 9, which is XML-based and extensible, using SIEM systems, automated vulnerability scanning. Using endpoint agents for visibility, like Palo Alto Networks Traps, or Cisco's AMP for endpoints. Or maybe running within your AnyConnect client, your Cisco AnyConnect mobility client Cisco umbrella, or some managed security service provider, MSSP, and for your SAS solutions, using a cloud access security broker to give you visibility and accounting. [Video description begins] The abbreviation for cloud access security broker is CASB. [Video description ends]
Information Life Cycle
There are a variety of security information life cycles or processes you can follow out there, there's no one size fits all. Here's one that has been presented for CISSP for quite a while. This is from Shon Harris, who wrote many of the CISSP books in the past. She was an outstanding veteran of the Air Force and a security professional who passed away well before her time. And Ms. Harris had this model, where we had phase 1: Plan and organize, phase 2: Implement, phase 3: Operate and maintain, And in phase 4: Monitor and evaluate.
There's also the traditional software development life cycle that can apply to our security initiatives. So this is a five-phase model. Here we have in phase 1: Initiation, phase 2: Development or acquisition, phase 3: Implementation, phase 4: Operation or maintenance, and the final phase: Disposition, or the disposal phase.
There's also the Policy and Process Life Cycle. This can be for your processes or for your security policy. First, we begin with IT risk identification. In that, of course, we'll also do some asset assessment and classification. Then, IT risk assessment, followed by Risk response and mitigation, finishing up with Risk and control monitoring and reporting. Hopefully you can see a pattern here.
A totally different model would be the Capability Maturity Model – CMM, which is often applied to organizations based on their kind of their security posture as far as the maturity of their security policy or the maturity level of their security implementation. So at Level 1, it would be a chaotic environment, kind of just an ad hoc or as needed, represented by individual heroics when necessary. [Video description begins] Level 1 is the Initial level. [Video description ends] The next level is Repeatable, where the process or the security service is not codified or well defined, and it's still vulnerable because it's an inconsistent state. Level 3 is more defined. So we're moving from inconsistency to where we have our processes defined and documented as standard business procedures. Level 4, [Video description begins] Level 4 is the Managed level. [Video description ends] which is kind of the most common for a mature organization, our security processes and controls are controlled. They can be adjusted, they can be adapted to particular projects without losing quality. Most mature organizations are at the Managed level. The fifth level, the highest level, which you can see here has the medal, is the Optimized level, where you got process management and deliberate process optimization and ongoing continual improvement.
Asset Inventory
Now, we've already determined that asset assessment is extremely important, especially early on in the risk management life cycle because we have to know the value of our assets in order to know how much time and resources and money to spend on our controls – administrative, technical, and physical – to protect those assets. Well, this is an ongoing endeavor, having an idea of the quantity and the value of your logical and physical assets.
So we want to have asset inventory control, especially in a medium-sized or large organization. Managing inventory will help you keep your corporate budget in line, including your security and IT budgets for protecting those assets. It also allows for the efficient management of operating capital. So we need to assess the type of inventory that we keep – physical, or computer based, determine the quantity of goods that we must keep on hand if our value proposition is to sell a product; we also want to track market trends of our competitors and identify the minimum necessary stock levels.
Just-in-time, JIT inventory is a modern phenomenon. It's a strategy that's used to increase efficiency and decrease waste by acquiring goods only as necessary in the production process, so we're actually having just what we need on hand, reducing inventory costs. But it does demand that producers precisely forecast the future demand for products and services; also being aware of certain events that can happen that can jeopardize the delivery of that particular inventory. So if there's a natural disaster or some other type of event that occurs, we need to have, as part of our business impact analysis and business continuity planning, how we're going to deal with the disruption in the flow of those products.
Many companies don't see the cost benefits beyond just using a spreadsheet or a simple database for asset inventory. But here's seven best practices for fixed asset inventory software. And again, when we talk about assets here, we don't just mean the assets that are part of our inventory for sale, okay – just the product sales assets, but all of the physical and logical assets that have value that must be protected by our security policy.
So first, we have to realize the scope of our asset inventory project. Second, we need to assign responsibility and give individuals with the skill set, the proper roles to manage assets. And then learn basic fixed asset procedures, often involving your finance department or accountants, CPAs, either in-house or third party. You want to rely on automated software going forward, okay. For any size business, this is a very easy thing to do, especially with software as a service solutions to the small business, where everything is stored in the cloud. You want to look for emerging technological trends, like software as a service and possibly using a CASB – a cloud access service broker. Ensure your employees, systems, and value proposition, and make sure you clear out those ghost assets.
Asset Management
Well now that we have our software inventory solution for our assets in place, we want to have our ongoing management and ongoing maintenance of our assets by tracking all physical and logical assets for their location, for their modification or change, and disposition. This leads to improved risk management and asset recovery for our business continuity plan. Whether an asset is real estate or software, the asset manager's main task is to supervise all the activities related to asset management.
Realize that the digital asset manager is a growing enterprise role, with the importance of content in today's modern enterprise. Automation and orchestration systems are vital for medium to large organizations' asset management. There's some key controls to implement to protect those valuable resources. You want an access control policy, maybe a MAC model, or an attribute-based access control, or identity and access management. [Video description begins] The abbreviation for access based attribute control is ABAC. The abbreviation for identity and access management is IAM. [Video description ends]
You want to use a zone-based boundary protection approach with next generation fire walls and intrusion prevention systems, continuous monitoring of your assets – and the state of those assets, including event auditing and visibility tools. And in addition to IDS and IPS, you want to have solid reporting and rapid response from incident response teams to any negative event or incident that would affect the value of our assets.
Might want to also consider device authentication and tracking mechanisms by using RFID tags or other asset tags, user authentication and authorization over the use of assets, encrypting data at rest and data in transit, performing ongoing vulnerability scanning on a regular basis. Consider cloud-based resource tracking and monitoring. Eventually the asset will be subject to your disposition or disposal policy. In the asset disposal process or phase, your plans are developed for discarding system information, hardware, and software, and possibly making the transition to a new system or a new asset. The information, hardware, and software may be moved to another system, it may be archived, it may be discarded, or destroyed.
If performed improperly, the disposal phase could result in the unauthorized disclosure of sensitive information, like personally identifiable information – PII, or personal health information – PHI, or IP – intellectual property. When archiving information, let's say you're using Amazon Web Service's Glacier service, your organization should consider the need and methods for future retrieval of that data.
The disposal activities will ensure the orderly termination of the system or asset and preserve vital information about that system or asset so that some or all of it can be reactivated in the future, if necessary. Particular emphasis is given to proper preservation of the data processed by the system so that data's effectively migrated to another system or archived in accordance with applicable records management regulations and policies for potential future access. The removal of information from a storage medium such as a hard disk or tape should be done in accordance with the organization's security policy or governance requirements based on HIPAA, PCI DSS, Sarbanes-Oxly, and others.
Configuration Management
Configuration management and change management are topics that really are going to move through this entire CISSP series. However, one thing I do want to define at this point in time, which is often a challenge for my students, especially in my ITIL version three training, is the difference between change management and configuration management. [Video description begins] The abbreviation for configuration management is CM. [Video description ends]
And let me make this very simple for you; you cannot have a change management without configuration management. You must first have a configuration item, okay – something that you can actually configure initially or create in order to be able to have a change to it. So, you have to have a configuration first in order to change that configuration. So we want to have the horse before the cart. And the horse would be the configuration management and then behind that, is the change management.
Configuration management is a governance and systems life cycle process for ensuring consistency among physical and logical assets. And these are called configuration items, or CIs because they should be in some configuration management database, or CMDB in your operational environment. The CM process involves classifying and tracking individual CIs, documenting functional capabilities and interdependencies between those configuration items, and verifying the effect the change has to one configuration item over some other system or entity. Configuration management and control activities should be performed to document any proposed or actual changes in the security plan of the system.
Now once that happens, that will be documented as part of your change management process. So here's change management where first we submit the ticket or the change proposal or the request for change, for example – RFC, to some type of advisory board, or some type of team, or service desk for approval. That's the second step. Once it's approved, it goes to the Documenting phase. Once that change is documented, it goes to the Testing phase, where you test that in a sandbox environment or a private cloud environment, either on-premise or let's say up at a cloud provider. And then you implement that change into production, and then you report that activity. And the reporting of the activity goes into the change management database.
Privileged Account Management
One important aspect of asset management is making sure that you're in control of the access to those particular assets. And so the type of accounts in most network operating systems and other types of access systems are going to be privileged accounts. But you're going to have root or admin access to a wide variety of different assets. So we want to understand these privileged accounts. We're going to spend some time here making sure that we have complete visibility into who's using those accounts and how they're used, and how they function with our assets. So privileged accounts get elevated access to systems using special credentials. Typically, you're going to get nonrestricted or at least highly elevated access to the system, service, or applications. Privileged accounts are designed for systems administrators to deploy and manage the IT infrastructure devices, the operating systems and the updates and upgrades, databases, applications, and more. These are the keys to the kingdom and they're the prime target of malicious external attackers and privileged insiders.
Here's a list of the most common privileged accounts. Obviously there's the root user accounts; and we've got a root user on systems like routers and switches and firewalls. We also have domain and forest administrators in let's say a Microsoft operating system. Really, any network operating system is going to have those system and domain administrators – local administrative accounts, for example. There's also privileged user accounts like an exec user on a router or a switch. There's emergency accounts and special application accounts that may be just for your web services or your e-mail services. Service accounts can be privilege local or domain accounts that are used by an application or service to function with a network operating system. And if you have a trust relationship, let's say across a forest, it could also have the ability to move across using that trust and access other resources in other domains. Some service accounts have domain administrative privileges contingent on the needs of the application, for example corporate mail, or database services. Local service accounts can operate with several different system components. So this renders the coordination of password changes challenging, especially on these special types of accounts and privileged accounts. Service account passwords are rarely changed. This can be a significant vulnerability for your enterprise.
Here we see the component services of a Microsoft Windows 10 system. And we can see a wide variety of different services here that are running and that are logged on as local system accounts. [Video description begins] A screenshot of a Component Services page displays. The list of services include Local Session Manager, Offline Source Engine, and Plug and Play. [Video description ends]
Legal Issues
We're going to switch gears here and talk about some legal considerations that, these are important aspects of security. Often, we have to rely upon other expertise – other expert judgement for legal matters, and so on the exam – the CISSP exam that you're expected to have a general idea of how security practitioners deal with legal considerations, that involves working with your in-house legal team or legal department or interfacing with third-party law firms, you need to have the right legal review and interpretation, especially for your agreements and your contracts for regulations for dealing with privacy and security issues, but also dealing with forensic investigations and law enforcement. The requirements that you have may fluctuate based on your jurisdiction or your geography. So it's going to be a different situation if you're dealing with United States or Canada versus, let's say, the EU. It's important to realize that legal teams are not always cognizant of all the regulatory or cybersecurity matters. These are heavily influenced by your privacy laws – HIPAA, PCI, or SOX. [Video description begins] Legal considerations are influenced by privacy laws such as PCI DSS. [Video description ends]
Keep in mind that regulatory compliance, however, is no different from the other aspects of risk management that we have to assess and analyze. Security strategies are significantly affected by regulatory mandates for IP, intellectual property, privacy, contracts, agreements, and civil and criminal law. Different business units or different regions may have distinct regulations and requirements. These regulations may relate to e-commerce, taxation, tariffs, the worldwide transmission of various data – for example, encrypted data, and trans-border information flow, including information flow through a cloud service provider.
There's also variances and cultural norms to be aware of – different customs, different sensitivity levels, and different behavior, for example, Europe versus the US, or Asia versus South America. Policies, controls and procedures will differ based on geographic region – the countries under different regulations and mandates, different forms of government. There's a wide variety of organizations you can look into – AGATE, IDABC, OBASHI, ITIL, ISO, TOGAF. These are all frameworks and architectures that can transcend geographic boundaries. The Department of Commerce's Bureau of Industry and Security, BIS, actually controls nonmilitary cryptographic exports. Keep that in mind for the exam. And the challenges of cloud computing, whether you're using Oracle or IBM, Google or Amazon, is going to transcend traditional boundaries and jurisdictional barriers, as data can be stored and replicated across multiple regions.
A security practitioner, specifically a CIO or a CISO, needs to have comprehensive insight into the applicable laws and regulations. A best practice is to keep data local whenever possible, and manage your encryption and your encryption keys. Access control and data security can be complicated by geographic and sovereignty issues. And geo-redundancy is a challenge, in other words, instances of configuration items or assets or data in multiple regions. So it's important to have big data solutions to de-duplicate these instances of data and assets.
Typical duties for your legal department, whether it's in-house or a third party, is to deal with contracts and agreements – different types of agreements, service-level agreements, NDAs, as well as litigation and negotiation. Legal can also assist information security with regulations, compliance, corporate liabilities, cybercrime, secondary loss events, due care and due diligence, and disputes in service level or interconnection level agreements. [Video description begins] The abbreviation for service level agreements is SLA. [Video description ends]
Also, don't forget the role that your insurance company and their legal services can play, especially when it comes to cybercrime, and understanding if you have coverage for various types of attacks, like ransomware, data breach, and other threats.
Service Level Agreements
So far in this course, I've eluded to different types of contracts and agreements, especially when it comes to understanding your responsibilities as a security practitioner and legal teams. So let's take a look at a survey here of different types of agreements that you might come in contact with starting with the NDA, the non-disclosure agreement.
This is a document that will protect people involved in a business relationship where there's a sharing of confidential information or proprietary intellectual property. It's also called a confidentiality statement or a confidentiality agreement or clause. The confidential relationship often relates to information being shared between entities, but should not be made available to the general public or a competitor. Here we can see an example, at NIST, of a non-disclosure agreement. It's a pretty long URL but if you follow this, you can get a default kind of template. [Video description begins] The URL is as follows: https://www.nist.gov/sites/default/files/documents/2017/01/12/nist_model_nda_disclosure_of_nist_information_v2016.1_filelable_for_website_002.pdf. [Video description ends]
Other agreements are the interconnection security agreement, the ISA. This is going to document and formalize connections between two organizations. So, for example, if you're going to create a direct connect between your company and maybe a provider that specializes in connecting you to Google Cloud Platform or Amazon Web Services, you may have an ISA with that third party organization. It's going to provide security and safeguards for your various connections, which hopefully are highly redundant. There's also an MOU or an MOA. MOU is the memorandum of understanding. MOA is the memorandum of agreement. This is an early document that's kind of signed to define responsibilities of each organization. So if we're using an MOU or an MOA along with our ISA, it will early on define the responsibilities of each organization for the connection; so establishing the connection, ongoing operations, and securing of the connection. Realize the MOU or MOA can be used with a wide variety of contracts and agreements, not just the ISA.
There's a business partners agreement between partners for business purposes. [Video description begins] The abbreviation for business partner agreement is BPA. [Video description ends] It's going to state the purpose of the business, the contributions of each partner, and the rights and responsibilities of each partner. And you may see this agreement before entering into an LLC or a partnership agreement.
The common SLA is the Service Level Agreement. This defines the precise responsibilities of a service provider. It also is going to set customer expectations. It'll clarify the support system, often the service desk response to problems or outages for an agreed level of service. The SLA can be internal within your organization or within your enterprise between business units or departments. Or it could be external between your company and, let's say, a cloud service provider or an MSSP, a managed security service provider. The SLA should be used in any new third-party vendor or cloud provider scenario for 24-hour support, whether it's SaaS, IaaS, or PaaS.
The Operational Level Agreement documents the pertinent information for regulating the relationship between internal service recipients and an internal IT area, like a service provider. [Video description begins] The abbreviation for operational level agreement is OLA. [Video description ends] The main difference between an SLA and an OLA is what the service provider is promising to the customer in the SLA, versus what the functional IT groups promise to each other in the OLA. The OLA often corresponds to the structure of an SLA, but it is internal. There are some components that are common to an external SLA and an internal OLA. The name of the service, clearance information with a date and time stamp, [Video description begins] In this instance, it's the name of the IT service. Clearance information includes location information. [Video description ends] contact information, the duration of the contract or the agreement, the description of services, the relationship to other IT services or other business units, the procedures for requesting the IT service, roles and responsibilities, quality assurance and service level reporting, service accounting, and finally, a glossary of terms.
Describing Operations Security Management
In this exercise, you'll list five critical security principles, list three types of agreements, name three types of privileged accounts, and list five controls used to implement asset management. Pause the video, go get your answers, and come back and we'll compare.
First, I asked for five security principles for operations. If you said any five of these, least privilege, defense in depth, rotation of duties, forced vacations, dual operator, compartmentalization and zoning, mediated access, or visibility and accounting, you got the correct answer.
Next, I asked for three types of agreements. If you mentioned any three of these, NDA, ISA, MOU or MOA, [Video description begins] NDA stands for non-disclosure agreement. ISA stands for interconnection security agreement. MOU/A stands for memorandum of understanding or agreement. [Video description ends] BPA, SLA, or OLA, then you got the correct answer. [Video description begins] BPA stands for business partners agreement. SLA stands for service level agreement. OLA stands for operational level agreement. [Video description ends]
Next I asked for three types of privileged accounts. Any three of these would do – root account, local admin, privileged user, forest administration, domain administration, emergency accounts, or application or service accounts. Any three of those and you got the correct answer.
Finally, I asked for five controls to implement asset management. If you said any five of these, for example, access control policies, [Video description begins] Access control policies include MAC, ABAC, and IAM. [Video description ends] continuous monitoring, incident detection and reporting, device authentication and tracking, data encryption, or vulnerability scanning – [Video description begins] Device authentication and tracking includes RFID . Other controls include zone-based boundary protection, event auditing and visibility, incident response teams and rapid response, user authentication, and tracking and monitoring all resources. [Video description ends] any five of these, you got the correct answer. Excellent.