CS205 — Final Term Summary (Lectures 23–43)

📘 Lecture 23 — What Does “Box Security” Mean? & Best Approach: IT Enterprise Security

📖 Overview: This lecture critiques the common industry practice of “box security,” where organizations purchase security devices without proper planning or staffing. It then introduces the 4-layer security transformation model as a more effective and practical approach to building a strong security posture, especially in environments with weak security awareness.

🗂️ Topics Covered

The lecture first defines “box security” and explains its prevalence, highlighting that security is a combination of people, process, and technology and that purchased devices are often underutilized. It then details the challenges with this approach, including staff shortages and lack of planning. Finally, it presents the 4-layer security transformation model as the best approach, covering security hardening, vulnerability management, security engineering, and security governance.

📝 Lecture Summary

Topic no 46: What Does “Box Security” Mean?

“Box Security” refers to a common industry approach, especially in larger organizations, where the solution for every security challenge is a dedicated device or “box.” Examples include boxes for email security, web security, firewalls (FW), IPS (Intrusion Prevention Systems), APT attack prevention (Advanced Persistent Threat), DDOS prevention (Distributed Denial of Service), Network DLP (Data Loss Prevention), and Network Forensics. However, this approach is flawed because security is a combination of people, process, and technology. Industry observation shows that most devices are not used to their full capability or capacity after purchase, with a case in point being SIEM (Security Information and Event Management) or DB security (Database Security) solutions.

The lecture emphasizes that “box security” is not a silver bullet. Although many devices and boxes are required, they do not ensure a good security posture, and this approach is unfortunately promoted by vendors who have equipment to sell. Other challenges include a shortage of IT and security staff, and the training and skills required to operate sophisticated devices and features. To mitigate these issues, device objectives and high-level-design (HLD) should be planned prior to commissioning, a minimum operational baseline and configuration should be documented in SOP (Standard Operating Procedure), and device feature set and configuration audits should be conducted on a periodic basis (annually).

💡 Why this matters: This topic highlights that simply buying security tools is ineffective without proper planning, staffing, and process integration. It sets the stage for the more holistic model that follows.

Topic no 47: Best Approach: IT Enterprise Security

The best approach is the 4-layer security transformation model, which is the only way to effectively and practically address security posture. This model is tried and tested for geographies where the overall security awareness and posture is weak. The four layers are:

1. Security hardening: This addresses the security configuration of all IT assets which security “boxes” won’t do for you. It is the foundational layer.
2. Vulnerability management: This involves scanning to inspect patching of IT assets and is considered essential. It is supported by security engineering and security governance.
3. Security engineering: This is where more serious investments may be made once layers 1 and 2 have been completed satisfactorily (or are being addressed). It focuses on architectural design and integration.
4. Security governance: This ensures the proper utilization (as intended), ROI (Return on Investment), and audits of purchased devices & solutions. It also ensures configurations are as per design and SOPs.

🔑 Definition — 4-layer security transformation model: A hierarchical framework that builds security posture from the ground up, starting with configuration (hardening) and vulnerability management before progressing to advanced engineering and governance. 📐 Order of Layers: Security Hardening (Layer 1) → Vulnerability Management (Layer 2) → Security Engineering (Layer 3) → Security Governance (Layer 4). The model is sequential, meaning layers 1 and 2 must be addressed before significant investment in layers 3 and 4. 📌 Example: An organization first hardens all its servers and endpoints (Layer 1), then sets up a scanning schedule to ensure all patches are applied (Layer 2). Only after this secure baseline is established does it invest in a new SIEM solution, ensuring the engineering (Layer 3) is based on a clean environment. Finally, governance (Layer 4) audits the SIEM’s configuration and usage to confirm it meets the original objectives and provides a return on investment.

🔑 Definition — Security hardening: The process of configuring IT assets (e.g., servers, workstations, network devices) to reduce their attack surface by disabling unnecessary services, setting strong passwords, and applying secure baseline configurations. 🔑 Definition — Vulnerability management: The continuous process of identifying, classifying, prioritizing, and remediating vulnerabilities in IT assets, typically through automated scanning and patching.

⭐ Key Takeaways

The lecture’s core message is that “box security” is an incomplete and often ineffective approach because it ignores the crucial elements of people, process, and planning, leading to underutilized devices and a false sense of security. The key to a strong security posture is the 4-layer security transformation model, which builds security from the ground up, starting with fundamental hardening and vulnerability management before adding advanced technologies. A student must remember that security devices are tools, not solutions, and their effectiveness depends entirely on the organizational maturity, staffing, and processes surrounding them. Finally, the sequence of the 4-layer model is critical—layers 1 and 2 must be addressed before significant investment in layers 3 and 4, and governance (Layer 4) is essential for ensuring ROI and proper use.

🧠 Quick Revision Questions

1. What is the core problem with the “box security” approach, and why does it not ensure a good security posture?
2. List the four layers of the security transformation model and explain their correct sequence.
3. Why is it important to plan device objectives and a high-level design (HLD) before commissioning a security device?
4. What is the primary goal of the “security hardening” layer, and how does it differ from “vulnerability management”?
5. What is the role of “security governance” in the 4-layer model, especially concerning previously purchased devices?

📘 Lecture 24 — DR In Enterprise Architecture – Part 1

📖 Overview: This lecture introduces Disaster Recovery (DR) and Business Continuity (BC) as critical security disciplines. It defines DR, its three-step process, and DR plan components, then distinguishes DR from BC, explaining BC management and planning. The lecture emphasizes the importance of RTO and RPO as key metrics in enterprise DR architecture.

🗂️ Topics Covered

The lecture covers the definition of disaster and disaster recovery, the three-step failover process, the DR plan checklist, the definition of business continuity and business continuity management, the BC plan, and then begins the topic of DR in enterprise architecture with detailed coverage of DR plan components, RTO, and RPO.

📝 Lecture Summary

Topic no 48: What Is Disaster Recovery (DR)?

A disaster is any significant event that causes disruption of information technology processing facilities, affecting business operations. Disaster Recovery (DR) is an area of security that allows an organization to maintain or quickly resume mission-critical IT functions following a disaster. The invocation of a DR failover to a DR site can be caused by natural disasters (flood, earthquake, lightning, storm) or disasters caused by human actions (riot, fire, terrorist act).

Disaster Recovery is an IT function, whereas Business Continuity (BC) addresses keeping all essential aspects of a business functioning despite disruptive events; DR is a part of BC.

The DR process involves three steps:

• Failover to the DR site (DR invocation)
• Restoration of the services/facilities on the primary site
• Recovery (switchover back to the primary site)

A DR plan is a documented, structured approach to dealing with unplanned incidents.

A DR plan checklist includes: scope of activity, gathering relevant network infrastructure documents, identifying the most serious threats/vulnerabilities and critical assets, identifying current DR strategies, identifying the emergency response team, management review & approval, testing the plan (drill), updating the plan, and implementing a DR plan audit.

Topic no 49: What is Business Continuity (BC)?

Business Continuity (BC) is the capability of the organization to continue delivery of products or services at acceptable predefined levels following a disruptive incident (Source: ISO 22301:2012). Business Continuity Management is a holistic management process that identifies potential threats and their impacts to business operations, and provides a framework for building organizational resilience with an effective response that safeguards interests of key stakeholders, reputation, brand, and value-creating activities (Source: ISO 22301:2012).

A BC plan is a document consisting of critical information an organization needs to continue operating during an unplanned event. The BCP should state essential functions of the business, identify which systems and processes must be sustained, and detail how to maintain them, taking into account any possible business disruption.

Topic no 50: DR In Enterprise Architecture – Part 1

DR considerations include the DR plan, RTO, and RPO. A comprehensive DR plan includes: a disaster recovery policy statement, plan overview, main goals, key personnel/DR team contact info, emergency response actions, a diagram of the entire network and recovery site, directions to the recovery site, a list of recovery software/systems, sample templates for technology recoveries, insurance coverage summary, actions for financial/legal issues, and ready-to-use forms.

🔑 Definition — RTO (Recovery Time Objective): The maximum amount of time, following a disaster, for an organization to recover files from backup storage and resume normal operations; the maximum amount of downtime an organization can handle.
📐 Formula: RTO = Maximum acceptable downtime → If an organization has an RTO of two hours, it cannot be down for longer than that.
📌 Example: An organization with an RTO of 2 hours must fully recover from backup and resume normal operations within 2 hours of a disaster.

🔑 Definition — RPO (Recovery Point Objective): The maximum age of files that an organization must recover from backup storage for normal operations to resume after a disaster; determines the minimum frequency of backups.
📐 Formula: RPO = Maximum acceptable data loss → Determines how frequently backups must occur.
📌 Example: If an organization has an RPO of four hours, the system must back up at least every four hours. This means in a disaster, no more than 4 hours of data can be lost.

💡 Why this matters: RTO and RPO are critical metrics that directly impact business risk and cost. A shorter RTO (faster recovery) and shorter RPO (less data loss) require more expensive infrastructure and more frequent backups.

Topic no 51: DR In Enterprise Architecture – Part 2

DR considerations include DR facility, DR drills & testing, DR testing checklist, and BC plan alignment.

A DR facility involves location, media circuits and backup circuits, power and environment, IT data center design based on the DR plan, and operations & maintenance.

DR drills & testing should follow frequency and execution as per IT policy, with a minimum of twice a year and preferably quarterly for critical business requirements. Backup testing is also included.

A DR testing checklist includes: secure management approval and funding, provide detailed test information, ensure full test team availability, avoid conflicts with other tests, confirm correct test scripts, verify test environment readiness, schedule a dry run, be ready to halt the test if needed, have a scribe take notes, complete an after-action report, and use test results to update the DR plan.

For BC plan alignment: DR is under IT ownership, whereas BC is under business operations ownership. DR is part of overall BC, and both plans must integrate and align seamlessly.

⭐ Key Takeaways

The most critical concept is that Disaster Recovery (DR) is an IT function focused on restoring mission-critical IT systems after a disaster, while Business Continuity (BC) is a broader business operations function that keeps all essential business aspects running. RTO (Recovery Time Objective) defines maximum acceptable downtime, and RPO (Recovery Point Objective) defines maximum acceptable data loss, both directly determining backup frequency and recovery infrastructure costs. DR follows a three-step process: failover to DR site, restoration of primary site, then recovery (switchback). A successful DR program requires a comprehensive DR plan, proper DR facility design, regular drills at least twice yearly, and seamless integration with the BC plan. Both plans must align under separate ownership — IT for DR and business operations for BC.

🧠 Quick Revision Questions

1. What is the difference between Disaster Recovery (DR) and Business Continuity (BC)?
2. What are the three steps in the DR process?
3. Define RTO and RPO. If an organization has an RPO of 4 hours, what does that mean for backup frequency?
4. According to IT policy, what is the minimum recommended frequency for DR drills?
5. Which ownership — IT or business operations — is responsible for the Disaster Recovery plan, and which is responsible for the Business Continuity plan?

📘 Lecture 25 — Role Of An IT Asset In Enterprise Security & How To Determine Security Posture?

📖 Overview: This lecture defines what constitutes an IT asset in an organization and explains the roles of asset and risk owners, as well as acceptable use policies for IT assets. It then provides a comprehensive set of diagnostic questions to assess an organization’s overall security posture, covering policies, hardening, vulnerability management, and disaster recovery.

🗂️ Topics Covered

The lecture first covers the definition of an IT asset (hardware, software, information, human resource, or facility), the distinct roles of asset owner and risk owner, and the concept of acceptable use for company assets like laptops, mobiles, and data. It then transitions to a detailed checklist of questions that help determine an enterprise’s security posture, including policy existence, security culture, team size, hardening standards, vulnerability scanning (VM), licensing, penetration testing, policy maturity, and disaster recovery drills.

📝 Lecture Summary

Topic no 52: Role Of An IT Asset In Enterprise Security

An IT asset is defined as any resource—such as hardware, software, information, human resource, or facility—that is owned or utilized by an organization for its IT processing. Understanding the different types of IT assets is crucial for effective security management. The asset owner is the person in the organization responsible for managing a specific asset, such as a laptop. 💡 Why this matters: Clear ownership ensures accountability for asset lifecycle and security.

🔑 Definition — IT asset: any resource such as hardware, software, information, human resource, or facility owned or utilized by the organization for IT processing.

🔑 Definition — Asset owner: a person in the organization responsible for managing an asset (e.g. for a laptop).

🔑 Definition — Risk owner: manages risks associated with the IT asset, is authorized to make decisions associated with managing risks, and is in a management position.

The lecture also defines Acceptable Use (Of IT Assets), which applies to laptops, mobiles, web browsing, email usage, servers, and company data. These policies govern how employees may use organizational resources.

📌 Example: An acceptable use policy for a company laptop would specify that it cannot be used for personal streaming services, ensuring the asset is used only for business purposes.

Topic no 53: How To Determine Security Posture?

To determine an organization’s security posture, a set of diagnostic questions must be asked. These questions cover multiple dimensions of security readiness and maturity. The first set of questions addresses policy and culture: Is there an information security policy? What is the organization’s security culture and tone at the top? Is there a clearly designated responsibility for security?

Next, the lecture asks about the security team: How many staff are in the security team (suggesting 10% as a benchmark) and what are their roles? Critical technical questions follow: Has security hardening been done on IT assets? Which standard was used for hardening (e.g., CIS, NIST)? Is there an internal vulnerability management (VM) program? What is the frequency of VM scanning?

The assessment continues with software compliance: Are all licensed software used for OS, databases, and programs? When was the last time a penetration test was conducted by a third party? The lecture also probes the maturity of system security policies pushed through Active Directory (AD) or Group Policy (GP). Finally, it asks about disaster recovery: Is there a DR and/or backup site? When was the last time a DR drill was performed?

📌 Example: If an organization has no internal VM program and has never performed a third-party penetration test, its security posture would be considered very low maturity, indicating high risk.

⭐ Key Takeaways

The most critical concepts from this lecture are: First, an IT asset encompasses hardware, software, information, human resources, and facilities, and each asset should have a designated asset owner and risk owner with distinct responsibilities. Second, acceptable use policies must be established for all major asset types including laptops, mobiles, email, and company data. Third, assessing an organization’s security posture requires a systematic checklist covering policy existence, security culture, team size (with a 10% staffing benchmark), hardening standards, vulnerability management (including scanning frequency), software licensing, third-party penetration testing, policy maturity through AD/GP, and disaster recovery readiness with regular DR drills.

🧠 Quick Revision Questions

1. What are the five categories of resources that constitute an IT asset according to this lecture?
2. What is the key difference in authority and responsibility between an asset owner and a risk owner?
3. List four specific types of IT assets for which organizations should define acceptable use policies.
4. What percentage of staff working in the security team does the lecture suggest as a benchmark for evaluating security posture?
5. Name three technical questions that should be asked to evaluate an organization’s security posture related to vulnerability management, penetration testing, and disaster recovery.

📘 Lecture 26 — Driving Successful Security Transformation & Revisit Of Security Transformation Model

📖 Overview: This lecture explains what makes security transformation projects succeed or fail, focusing on critical success factors like board-level sponsorship and resource allocation. It then revisits the security transformation model, detailing the two essential technical processes—hardening and patching—that protect IT assets from vulnerabilities and attacks.

🗂️ Topics Covered

The lecture covers critical success factors for security transformation projects, including board-level buy-in, regular executive reviews, and resource allocation. It then introduces the security transformation stage from Chapter 3, explaining the concepts of security hardening (reducing system vulnerability surface) and patching (fixing software/firmware vulnerabilities), along with their differences and complementary roles.

📝 Lecture Summary

Topic no 54: Driving Successful Security Transformation

Successful security transformation projects depend on several critical factors that determine their outcome from the start. The most important factor is board-level buy-in and sponsorship, which ensures that security initiatives have top-down support and authority. Additionally, regular Board or Executive management project reviews and decisions keep the project aligned with organizational priorities and allow for timely adjustments. Finally, the allocation of sufficient priority & resources ensures that the project has the funding, personnel, and attention it needs to succeed.

💡 Why this matters: The lecture emphasizes that "projects either fail or succeed before they begin!" This means that without proper sponsorship, structure, strategy, and strong project management, even technically sound security initiatives are likely to fail. Success is determined by organizational commitment and governance, not just technical measures.

Topic no 55: Revisit Of Security Transformation Model

Security Hardening IT assets such as hardware and software come with default (insecure) configurations which become the basis for attacks. A typical case in point is the default username and password combination of "admin, admin" which attackers can easily exploit. Hardening makes a system more secure by reducing its surface of vulnerability, which is larger when a system performs more functions; in principle, a single-function system is more secure than a multipurpose one.

🔑 Definition — Hardening: Additional steps beyond patching to limit the ways a hacker or malware could gain entry, accomplished by turning on only the ports and services required, secure configuration of services, and additional steps to limit system access.

Patching Patching involves fixing vulnerabilities (which may be exploited by malware or attackers) in software or firmware with vendor-released patches (auto or manual updates). Patches are also called fixes. Patching considerations include: vendors release a patch when they become aware of a vulnerability; patches may be rolled up into a release; off-the-shelf software works well but testing is required for customized instances.

🔑 Definition — Patching: The process of applying vendor-released updates to fix vulnerabilities in software or firmware that could be exploited by malware or attackers.

Relationship Between Hardening and Patching Note that both hardening and patching are required. Hardening prevents existing and future vulnerabilities by tightening configuration, while patching is more of a vendor-driven process but essential nonetheless. They serve complementary roles: hardening proactively reduces the attack surface, while patching reactively fixes known vulnerabilities.

📐 Formula: Security Hardening + Patching = Comprehensive Vulnerability Management → Hardening addresses configuration weaknesses proactively; patching addresses software flaws reactively; both are necessary for complete protection.

⭐ Key Takeaways

Students must remember that successful security transformation depends more on organizational factors (board sponsorship, regular reviews, resource allocation) than on technical measures alone. Both hardening and patching are essential and complementary: hardening reduces the attack surface by tightening default configurations and disabling unnecessary services, while patching fixes known vulnerabilities through vendor updates. A single-function system is inherently more secure than a multipurpose one because it has a smaller vulnerability surface. Remember that "projects either fail or succeed before they begin" — preparation and organizational commitment are the foundation of success. Finally, the default "admin, admin" example illustrates how insecure default configurations can become the entry point for attacks.

🧠 Quick Revision Questions

1. What are the three critical factors for successful security transformation projects?
2. Why do projects "either fail or succeed before they begin"?
3. What is the difference between hardening and patching?
4. Why is a single-function system considered more secure than a multipurpose one?
5. What is the typical example given for insecure default configurations in IT assets?

📘 Lecture 27 — Security Hardening Strategy

📖 Overview: This lecture introduces the concept of security hardening as a practical, priority-driven approach to securing IT assets. It emphasizes the importance of separating quick, baseline security measures from more complex security engineering tasks to achieve rapid risk reduction.

🗂️ Topics Covered

The lecture covers the definition and importance of security hardening as a distinct initial step in the security implementation process. It explains the role of priority in managing numerous assets, introduces the concept of the Minimum Security Baseline (MSB), and describes the "cascade" approach for progressive security improvements.

📝 Lecture Summary

Security Hardening Strategy

Depending on the size and type of the organization, there may be dozens, hundreds, or even thousands of IT assets to secure. Priority is a key factor in all security undertakings. You must prioritize what is most important and needs to be done first, then cascade as you go along.

💡 Why this matters: Without prioritization, security teams can become overwhelmed by the sheer volume of assets, leading to analysis paralysis and no actual security improvements.

Separate Security Engineering from Security Hardening

It is critical to separate security engineering (Step 3) from security hardening (Step 1). Security engineering requires more thorough working and will slow down the security implementation. Therefore, organizations should do the low hanging fruit first, which is security hardening.

🔑 Definition — Security Hardening: The process of securing a system by reducing its surface of vulnerability, typically by applying basic, quick, and obvious security measures.

🔑 Definition — Security Engineering: A more thorough and complex process of designing and building security into systems from the ground up, requiring more time and analysis.

Minimum Security Baseline (MSB)

The Minimum Security Baseline (MSB) refers to the obvious assets which need to be secured and the threshold which is the minimum expectation from the security program.

🔑 Definition — Minimum Security Baseline (MSB): The set of basic, essential security controls and configurations that must be applied to all assets as the starting point for security, representing the lowest acceptable level of protection.

📌 Example: An organization with 500 workstations might identify that all of them need antivirus software, password policies, and disabled guest accounts. The MSB would be deploying these three controls across all 500 machines before moving on to more complex security measures like firewall rule optimization or intrusion detection tuning.

⭐ Key Takeaways

The most critical understanding from this lecture is that security hardening must be separated from security engineering to avoid slow implementation. Priority is the key factor when dealing with large numbers of assets, and the "cascade" approach allows for progressive security improvements. The Minimum Security Baseline (MSB) represents the obvious, essential security controls that must be applied first as the minimum expectation. Organizations should always focus on the "low hanging fruit" — quick, easy wins — before tackling complex security engineering tasks.

🧠 Quick Revision Questions

1. Why is it important to separate security hardening from security engineering?
2. What does the term "cascade" mean in the context of the security hardening strategy?
3. What is the Minimum Security Baseline (MSB) and why is it important?
4. Why is priority considered a key factor in security undertakings?
5. What does "low hanging fruit" refer to in security implementation?

📘 Lecture 28 — Pre-requisites For Security Hardening

📖 Overview: This lecture explains the essential pre-requisites needed before starting a security hardening project, identifies the key stakeholders involved in conducting security hardening, and introduces the 8-step methodology for standardizing the hardening process. Understanding these foundations ensures a structured, disciplined, and effective approach to improving an organization’s security posture.

🗂️ Topics Covered

The lecture covers five pre-requisites for security hardening: a security program approved, a consultant on board, a project kick-off meeting held, ISMC team identified and their loading communicated, and appraisal linkage of core resources announced by CIO. It then details the roles of IT operations teams, InfoSec team, IT management, consultant, and business stakeholders in conducting hardening. Finally, it introduces the 8-step security hardening methodology, its purpose, benefits, and risks of skipping it.

📝 Lecture Summary

Pre-requisites For Security Hardening

For a successful security transformation project, good planning, organization, and effective project management are essential. Five key pre-requisites must be in place before commencing security hardening.

1. Security program approved – This includes defining the project director, establishing a timeline, agreeing on the general project sequence and strategy, understanding the main players and their roles, and clarifying the project structure.

2. Consultant on board – Expert consultants in security transformation can facilitate project success. They should be third-party and independent, bring a focus on delivering results, and possess strong domain knowledge.

3. Project kick-off meeting held – This ensures all key stakeholders are aware of the project goals & mission, their responsibilities & authority, the success criteria, and the reporting mechanism.

4. ISMC team identified and their loading for this project communicated – The ISMC (Information Security Management Committee) plays a critical role. This ensures cooperation & teamwork, fosters a security leadership culture, and provides clarity on goals.

5. Appraisal linkage of core resources announced by CIO – The broader team is informed, the announcement is made by the CIO (Chief Information Officer), and there is clarity on the evaluation mechanism for performance.

💡 Why this matters: Without these pre-requisites, security projects lack direction, accountability, and executive support, making failure highly likely.

Who Will Conduct The Security Hardening?

Security hardening involves the involvement of various stakeholders, each with distinct responsibilities.

• IT Operations teams: Study the security controls (e.g., CIS (Center for Internet Security) / DISA (Defense Information Systems Agency) standards), apply the security controls in a pilot/test environment, report the completion of control implementation to ISMC, and assist the InfoSec team with validation.

• InfoSec team: Conduct validation of security controls implementation, acquire a checklist of controls from the relevant IT team, document the status of controls in the form of a checklist, and forward the validation report to ISMC.

• IT management: Ensure IT operations teams receive required guidance and support, sign-off on change management requests, and assist with planning downtime and business-related downtime.

• Consultant or project director: Drives the security program, ensures that strategy is aligned with project objectives, and ensures process and activities are moving at good momentum as per the timeline.

• Business stakeholders: Provide downtime approvals if required, and help to engage other vendors if applicable.

8 Step Methodology – Security Hardening (1)

The 8-step security hardening methodology is a standardized approach to hardening assets.

Purpose: Many assets need to be hardened at various times, by various teams, for various requirements and projects. This methodology is designed to standardize and follow a consistent approach.

Benefits:

• Provides a clear process for security hardening
• Instills discipline to always follow the same steps
• Helps avoid missing any steps in the process
• Gives the team clarity on what to do and what sequence to follow

If You Skip This Process:

• You will follow a new approach every time
• Every resource has their own method
• Creates dependence on the resource rather than the process
• Complicate rather than simplify
• Leads to divergence in security activities

⭐ Key Takeaways

For a security hardening project to succeed, five pre-requisites must be met: an approved security program, a hired consultant, a completed kick-off meeting, a designated ISMC team, and appraisal linkage announced by the CIO. The actual hardening work involves multiple stakeholders: IT operations apply the controls, InfoSec validates, IT management supports, the consultant drives strategy, and business stakeholders authorize downtime. The 8-step methodology provides a standardized, disciplined approach that prevents reliance on individual resource methods and ensures consistency across all hardening activities. Skipping this methodology leads to divergence, complexity, and process failure. Memorize the five pre-requisites and the roles of each stakeholder group for the exam.

🧠 Quick Revision Questions

1. List all five pre-requisites for security hardening as taught in this lecture.
2. What is the primary responsibility of the InfoSec team when conducting security hardening?
3. What are the three main benefits of using the 8-step security hardening methodology?
4. Who is responsible for signing off on change management requests during hardening?
5. What is the role of the business stakeholders in the security hardening process?

📘 Lecture 29 — 8 Step Methodology – Security Hardening (2)

📖 Overview: This lecture completes the 8-step methodology for security hardening, detailing the final steps from testing through production deployment. It then provides an in-depth look at two major security benchmark frameworks—CIS Benchmarks and DISA STIGs—including their structure, content examples, and a comparison to guide organizational selection.

🗂️ Topics Covered

The lecture covers steps 5–8 of the security hardening methodology (implement controls on test setup, validate implementation, change management for production, and production deployment with monitoring). It then examines CIS security benchmarks for network devices and operating systems, explores DISA STIGs including their viewer, checklist screens, and specific STIG examples for Windows Server 2012 R2 and firewalls, and concludes with a comparison of CIS vs. DISA and a practical hardening example for Windows Server 2012R2.

📝 Lecture Summary

Topic no 60: 8 Step Methodology – Security Hardening (2)

This lecture continues the 8-step methodology for security hardening. Step 1 involves identifying critical assets and asset owners, creating an asset inventory and infrastructure diagram, examining risks, analyzing assets at a high level to prioritize, establishing a minimum security baseline (MSB), and breaking the work into phases. Step 2 is researching applicable security controls from sources like CIS, DISA, Google searches, and reviewing standards/frameworks such as ISO27001, PCI, OWASP, CSA, NIST, and CIS Top 20, followed by selection of controls. Step 3 creates a checklist of applicable security controls for progress tracking, sharing with the appropriate IT team, and forming a record for controls trail. Step 4 documents controls into a Standard Operating Procedure (SOP), enters the controls set into a draft SOP, defines who will do what when (and briefly how), and gets Department Head agreement and sign-off on the checklist and SOP.

Topic no 61: 8 Step Methodology – Security Hardening (3)

Step 5 involves implementing controls on a test setup by the relevant IT team, updating the checklist and SOP if necessary, and sending the checklist back to the InfoSec team. Step 6 is validation of control implementation by the InfoSec team, requiring an InfoSec resource with relevant domain knowledge, conducting preparation before actual validation (studying controls), and updating the checklist with a status column. Step 7 is the change management process for PRODUCTION, where the ISMC (Information Security Management Committee) receives validation status from the InfoSec team, the relevant department head takes up the change management process and prepares for shifting to PROD, considering rollback, impact, etc. Step 8 implements controls on PROD and monitors closely for 24-48 hours after moving to PROD, with rollback in case of unforeseen circumstances; the IT team SOP is finalized and becomes an operations task.

Topic no 62-65: A Look At CIS Security Benchmarks (1)

The Center for Internet Security (CIS) provides security benchmarks available at https://www.cisecurity.org/cis-benchmarks/. Users fill out details and receive an email with a download link. CIS benchmarks cover mobile devices, network devices, desktop software, and multifunction print devices. A CIS benchmarks example for network devices (dated June 29, 2016, 174 pages PDF) includes control content: profile applicability (e.g., ASA 8.X, ASA 9.X), description, rationale, audit, remediation, default value, and references. For example, control 1.8 (page 88): Session Timeout — Profile applicability: Level 1, Cisco ASA9.X; Description: Sets the idle timeout for a console session before the security appliance terminates it; Rationale: Limiting session timeout prevents unauthorized users from using abandoned sessions to perform malicious activities.

A CIS benchmarks example for operating systems (MS Windows Server 2012-R2, dated January 31, 2017, 760 pages PDF) includes profile applicability with Level 1 and Level 2 profiles. Level 1 items are intended to be practical and prudent, provide a clear security benefit, and not inhibit the utility of the technology beyond acceptable means. Level 2 extends Level 1, intended for environments where security is paramount, acts as a defense in depth measure, but may negatively inhibit utility or performance. Control content includes profile applicability, description, rationale, audit, remediation, impact, default value, and references. For example, control 1.1.2 [L1]: Ensure 'Maximum password age' is set to '60 or fewer days, but not 0' (Scored) — Profile applicability: Level 1 Domain Controller, Level 1 Member Server; Description: defines how long a user can use their password before it expires, values range from 0 to 999 days (0 means password never expires); Audit: Navigate to UI Path in Remediation section and confirm prescribed setting; Default Value: 42 days; Reference: CCE-37167-4 (Common Configuration Enumeration — unique identifiers for common system config issues).

Topic no 66: A Look At DISA STIGs (1)

DISA STIGs (Security Technical Implementation Guides) come from the USA DoD and are the most expansive security benchmarks available, most regularly updated, with an unclassified version available at http://iase.disa.mil/stigs/Pages/index.aspx. There are 425 STIGs available. Resources include a STIGs master list (A-Z) at http://iase.disa.mil/stigs/Pages/a-z.aspx and a STIG viewer at http://iase.disa.mil/stigs/Pages/stig-viewing-guidance.aspx. The STIG viewer can be downloaded, and a STIG library compilation is available. DISA STIGs use a completely different mechanism compared to CIS.

🔑 Definition — STIG: Security Technical Implementation Guide — expansive, regularly updated security benchmarks from the USA DoD.

Topic no 67: A Look At DISA STIGs (2)

STIG content includes: general information (title), discussion, check content, fix text, and CCI (Control Correlation Identifier) references. Checklist screens show: overall totals, target data, role, finding details, and comments. Status options include: Not reviewed, Open, Not a finding, and Not applicable.

Topic no 68: A Look At DISA STIGs (3)

Example: Windows Server 2012 R2 Member Server — Import STIG, V1099 (Lockout duration). Rule Title: The lockout duration must be configured to require an administrator to unlock an account — Severity: CAT II. Discussion: The account lockout feature prevents brute-force password attacks; this parameter specifies the period an account remains locked after failed logon attempts; a value of 0 requires an administrator to unlock the account. Check Content: Verify in Local Group Policy Editor (gpedit.msc) → Local Computer Policy → Computer Configuration → Windows Settings → Security Settings → Account Policies → Account Lockout Policy; if "Account lockout duration" is not set to "0", this is a finding. Fix Text: Configure the policy value for the same path to "0" minutes — "Account is locked out until administrator unlocks it". CCI: NIST SP 800-53 Revision 4 :: AC-7 b.

Topic no 69: A Look At DISA STIGs (4)

Example: Firewall Security Technical Implementation Guide — Vulnerability ID: V-3967; Rule name: The console port does not timeout after 10 mins. General Information: Rule Title: The network devices must time out access to the console port at 10 minutes or less of inactivity; STIG ID: NET1624; Severity: CAT II. Discussion: Terminating idle sessions reduces the window of opportunity for unauthorized personnel to take control of unattended management sessions and frees up resources; setting timeout to 10 minutes or less increases protection for critical network components. Check Content: Review configuration and verify console port session times out after 10 minutes or less of inactivity; if not, this is a finding. Fix Text: Configure the timeout for idle console connection to 10 minutes or less.

Topic no 70: Comparison of CIS Vs DISA

Many controls are common between CIS and DISA, but approaches and organization styles are different. Selection considerations: size of organization, IT infrastructure extent, nature of business, security program goals, and maturity of IT & security staff. Rule of thumb: Smaller organizations use CIS, larger organizations use DISA. CIS is part of Homeland Security, DISA is part of the US Military. DISA is more frequently updated and maintained with wider coverage.

Topic no 71: Security Hardening – Windows Server 2012R2

Example: Windows Server 2012 R2, DISA Release 8 (28 April 2017), Domain Controller. Rule Title: Autoplay must be disabled for all drives — STIG ID: WN12-CC-000074; Severity: CAT I. Discussion: Allowing Autoplay to execute may introduce malicious code; Autoplay begins reading from a drive as soon as media is inserted; by default, Autoplay is disabled on removable drives and network drives but not CD-ROM; enabling this policy disables Autoplay on all drives. Check Content: If registry value does not exist or is not configured as specified, this is a finding — Registry Hive: HKEY_LOCAL_MACHINE; Registry Path: \SOFTWARE\Microsoft\Windows\CurrentVersion\policies\Explorer; Value Name: NoDriveTypeAutoRun; Type: REG_DWORD; Value: 0x000000ff (255). Fix Text: Configure policy for Computer Configuration → Administrative Templates → Windows Components → AutoPlay Policies → "Turn off AutoPlay" to "Enabled: All Drives". CCI: CCI-001764 — The information system prevents program execution in accordance with organization-defined policies regarding software program usage and restrictions and/or rules authorizing the terms and conditions of software program usage (NIST SP 800-53 Revision 4 :: CM-7 (2)).

⭐ Key Takeaways

The 8-step hardening methodology proceeds from identifying assets through production deployment with monitoring. CIS Benchmarks and DISA STIGs are the two primary security benchmark frameworks, with CIS being more accessible for smaller organizations and DISA being more comprehensive, frequently updated, and suited for larger organizations. Both frameworks provide detailed controls with descriptions, rationales, audit procedures, and remediation steps, but use different organization styles. Key STIG severity levels are CAT I (most critical) and CAT II. Understanding how to navigate CIS benchmark documents and DISA STIG viewer, including interpreting profile applicability (Level 1 vs. Level 2 for CIS; CAT I vs. CAT II for DISA), is essential for implementing security hardening in real-world environments.

🧠 Quick Revision Questions

1. What are the four criteria used in Step 2 to research applicable security controls?
2. What is the purpose of Step 6 (Validation of control implementation) and who performs it?
3. In CIS benchmarks, what distinguishes Level 1 from Level 2 profile applicability?
4. What is the CCI (Control Correlation Identifier) and which standard does it reference in DISA STIGs?
5. According to the rule of thumb, which benchmark framework (CIS or DISA) is recommended for smaller organizations and why?

📘 Lecture 30 — Security Hardening – Case Studies

📖 Overview: This lecture presents five detailed case studies of security hardening applied to different operating systems and applications, including Linux, Solaris, Apache, Oracle, and MS SQL Server. Using real-world benchmark documents from CIS and DISA, it demonstrates how to audit and remediate specific security vulnerabilities to reduce attack surfaces and enforce least privilege.

🗂️ Topics Covered

The lecture covers security hardening case studies for Red Hat Enterprise Linux 7 (CIS Benchmark), Solaris 10 X86 (DISA STIG), Apache Tomcat 7 (CIS Benchmark), Oracle Database 12c (DISA STIG), MS SQL Server 2012 (CIS Benchmark), and Oracle Database 11.2g (DISA STIG). Each case study presents a specific rule, including description, rationale, audit procedure, remediation, and control correlation identifiers.

📝 Lecture Summary

Topic no 72: Case Study Security Hardening – Linux

This case study is based on the CIS Benchmarks for Red Hat Enterprise Linux 7 (January 31, 2017, 347-page PDF). The specific rule covered is 5.2.2 (page 258): Ensure SSH Protocol is set to 2 (Scored). This rule applies to Level 1 profiles for both Server and Workstation.

SSH supports two incompatible protocols: SSH1 and SSH2. SSH1 was the original protocol and was subject to security issues, while SSH2 is more advanced and secure. The rationale is that SSH v1 suffers from insecurities that do not affect SSH v2.

The audit procedure requires running the command # grep "^Protocol" /etc/ssh/sshd_config and verifying the output shows Protocol 2. The remediation involves editing the /etc/ssh/sshd_config file to set the parameter as follows: Protocol 2.

This rule maps to Critical Controls: 3.4 Use Only Secure Channels For Remote System Administration. The recommendation is to perform all remote administration of servers, workstations, network devices, and similar equipment over secure channels. Protocols such as telnet, VNC, RDP, or others that do not actively support strong encryption should only be used if performed over a secondary encryption channel, such as SSL, TLS, or IPSEC.

🔑 Definition — SSH Protocol 2: The more advanced and secure version of the SSH protocol, replacing the insecure SSH1.

📐 Rule: SSH Protocol must be set to 2 → Ensures only the secure SSH2 protocol is used for remote administration.

📌 Example: To harden an RHEL7 SSH server, a system administrator edits /etc/ssh/sshd_config, sets Protocol 2, and restarts the SSH service, preventing any SSH1 connections.

Topic no 73: Security Hardening – Case Study – Solaris

This case study is based on DISA (Defense Information Systems Agency) for Solaris 10 X86, Release 18 (28 April 2017). The rule is: All shell files must have mode 0755 or less permissive (STIG ID: GEN002220, Severity: CAT I).

The discussion explains that shells with world/group-write permissions give the ability to maliciously modify the shell to obtain unauthorized access.

The check content procedure: if /etc/shells exists, check the group ownership of each shell referenced using # cat /etc/shells | xargs -n1 ls -lL. Otherwise, check any shells found on the system using # find / -name "*sh" | xargs -n1 ls -lL. If a shell has a mode more permissive than 0755, this is a finding.

The fix text is to change the mode of the shell: #chmod 0755 <shell>.

The CCI (Control Correlation Identifier) is CCI-000225: The organization employs the concept of least privilege, allowing only authorized accesses for users (and processes acting on behalf of users) which are necessary to accomplish assigned tasks. This maps to NIST SP 800-53 :: AC-6.

🔑 Definition — 0755 permission: A file permission mode where the owner has read, write, and execute (7), and the group and others have read and execute (5), but no write access.

📐 Rule: Shell files must have mode ≤ 0755 → Prevents unauthorized modification of shell executables.

📌 Example: If a shell like /bin/bash has permissions 0777 (world-writable), an attacker could modify it to execute malicious commands. The fix changes it to 0755 (chmod 0755 /bin/bash), removing write access for group and others.

Topic no 74: Case Study Security Hardening – Apache

This case study is based on the CIS Benchmarks for Apache Tomcat 7 (April 26, 2016, 94-page PDF). The specific rule is 7.7 (page 65): Configure log file size limit (Scored) (Profile applicability: Level 2).

The description explains that by default, the logging.properties file will have no defined limit for the log file size. This is a potential denial of service attack as it would be possible to fill a drive or partition containing the log files.

The rationale is that establishing a maximum log size that is smaller than the partition size will help mitigate the risk of an attacker maliciously exhausting disk space.

The audit requires validating that the max file limit is not greater than the size of the partition where the log files are stored.

The remediation is to create the following entry in the logging.properties file (value specified in bytes): java.util.logging.FileHandler.limit=10000. The default value is no limit.

🔑 Definition — Denial of Service (DoS) attack via log files: An attacker fills the disk partition with log entries until no space remains, causing system failure.

📐 Rule: Configure log file size limit → Prevents disk exhaustion by capping log file growth.

📌 Example: An Apache Tomcat server has no log size limit. An attacker sends many requests, filling the /var/log partition. This causes the server to crash. The fix sets java.util.logging.FileHandler.limit=10000 (10KB), preventing unlimited log growth.

Topic no 75: Security Hardening – Case Study – Oracle

This case study is based on DISA for Oracle Database 12c, Release 18 (28 April 2017). The rule is: The Oracle Listener must be configured to require administration authentication (STIG ID: O121-BP-022700, Severity: CAT I).

The discussion explains that Oracle listener authentication helps prevent unauthorized administration of the Oracle listener. Unauthorized administration of the listener could lead to DoS exploits, loss of connection audit data, unauthorized reconfiguration, or other unauthorized access. This is a Category I finding because privileged access to the listener is not restricted to authorized users.

The check content: If a listener is not running on the local database host server, this check is not a finding. For Windows hosts, view all Windows services with TNSListener embedded in the service name in the format Oracle[ORACLE_HOME_NAME]TNSListener. View the STIGVIEWER for Unix hosts.

The fix text states that by default, Oracle Net Listener permits only local administration for security reasons. The listener can be administered only by the user who started it, enforced through local operating system authentication. For example, if user1 starts the listener, then only user1 can administer it. The super user is the only exception. Remote administration of the listener must not be permitted. If required, granting secure remote access to the Oracle DBMS server and performing local administration is preferred.

The CCI is CCI-000366: The organization implements the security configuration settings (NIST SP 800-53 :: CM-6 b).

💡 Why this matters: Unauthenticated listener administration is a severe risk. An attacker could stop the listener (DoS) or overwrite audit logs to hide malicious activity.

🔑 Definition — Oracle Listener: A network service that listens for incoming client connections to the Oracle database.

📐 Rule: Require administration authentication for Oracle Listener → Prevents unauthorized control of the listener service.

📌 Example: If an Oracle listener allows remote administration without authentication, an attacker on the network could issue lsnrctl stop to stop the database listener, causing a denial of service. The fix enforces local OS authentication so only the user who started the listener (or superuser) can administer it.

Topic no 76: Case Study Security Hardening – MS SQL

This case study is based on the CIS Benchmarks for MS SQL Server 2012 (September 30, 2016, 73-page PDF). The specific rule is 2.14 Ensure 'sa' Login Account has been renamed (Scored) (Profile applicability: Level 1 database engine).

The description explains that the sa account is a widely known and often widely used SQL Server account with sysadmin privileges. The rationale is that it is more difficult to launch password-guessing and brute-force attacks against the sa account if the username is not known.

The audit procedure uses the following syntax to determine if the sa account is renamed: SELECT name FROM sys.server_principals WHERE sid = 0x01; A name of sa indicates the account has not been renamed.

The remediation is to replace the different_user value within the below syntax and execute rename the sa login: ALTER LOGIN sa WITH NAME = <different_user>;

The impact is that it is not a good security practice to code applications or scripts to use the sa account. If this has been done, renaming the sa account will prevent scripts and applications from authenticating to the database server and executing required tasks or functions. The default value is that the 'sa' account name is 'sa'.

🔑 Definition — sa account: The default system administrator account in Microsoft SQL Server with full sysadmin privileges (SID = 0x01).

📐 Rule: Rename the 'sa' login account → Hides the well-known privileged account to prevent targeted attacks.

📌 Example: An attacker knows that most SQL Servers have an 'sa' account. They attempt a brute-force attack on 'sa'. If the account is renamed to 'Admin_DB', the attacker's guess of 'sa' fails, making the attack harder. The fix executes ALTER LOGIN sa WITH NAME = Admin_DB;.

Topic no 77: Security Hardening – Case Study – Oracle

This case study is also based on DISA for Oracle database 11.2g, Release 11 (28 April 2017). The rule is: The Oracle REMOTE_OS_ROLES parameter must be set to FALSE (STIG ID: O112-BP-022000, Severity: CAT I).

The discussion explains that setting REMOTE_OS_ROLES to TRUE allows operating system groups to control Oracle roles. The default value of FALSE causes roles to be identified and managed by the database. If REMOTE_OS_ROLES is set to TRUE, a remote user could impersonate another operating system user over a network connection.

The check content uses SQL*Plus: select value from v$parameter where name = 'remote_os_roles'; If the returned value is not FALSE or not documented in the System Security Plan as required, this is a Finding.

The fix text: Document remote OS roles in the System Security Plan. If not required, disable use of remote OS roles. From SQL*Plus: alter system set remote_os_roles = FALSE scope = spfile; This command sets the parameter to take effect at next system startup.

The CCI is CCI-000366: The organization implements the security configuration settings (NIST SP 800-53 :: CM-6 b).

💡 Why this matters: Allowing OS roles to control database roles can lead to privilege escalation, where a remote attacker gains database roles they should not have.

🔑 Definition — REMOTE_OS_ROLES: An Oracle parameter that, when TRUE, allows operating system groups to control Oracle database roles remotely.

📐 Rule: Set REMOTE_OS_ROLES = FALSE → Ensures database roles are managed by the database, not by external OS groups.

📌 Example: If REMOTE_OS_ROLES=TRUE, a remote attacker who gains access to an OS group like "dba" on the client machine could gain DBA privileges in the Oracle database. The fix sets remote_os_roles=FALSE, so only the database manages role assignments.

⭐ Key Takeaways

The key takeaway is that security hardening follows a standard pattern across different systems: identify a specific vulnerability (like weak SSH protocols, writable shell files, unlimited logs, unauthenticated listeners, default accounts, or OS-controlled roles), understand the risk (DoS, privilege escalation, unauthorized access), audit for compliance using specific commands, and remediate by applying configuration changes. Each case study maps to recognized security frameworks (CIS Benchmarks, DISA STIGs, NIST SP 800-53, Critical Controls), and many vulnerabilities are categorized as CAT I (highest severity), meaning they pose immediate and severe risks. A security professional must know how to read these benchmark documents, perform audits using command-line tools, and apply specific remediation steps for different operating systems and applications.

🧠 Quick Revision Questions

1. What is the remediation command to ensure SSH Protocol is set to 2 on a Linux system?
2. Why must shell files have a mode of 0755 or less permissive on Solaris?
3. What specific parameter must be added to logging.properties to prevent a DoS attack via log file exhaustion in Apache Tomcat?
4. What is the danger of not requiring administration authentication for the Oracle Listener, and how is it prevented?
5. Why should the 'sa' login account be renamed in MS SQL Server, and what SQL command is used to do so?

📘 Lecture 31 — Case Study Security Hardening – Windows 8

📖 Overview: This lecture presents a real-world case study of security hardening using the CIS Benchmarks for Windows 8.1. It demonstrates how a specific security configuration recommendation—disabling automatic sending of memory dumps—is documented, justified, and implemented, showing students the practical application of security hardening standards in enterprise environments.

🗂️ Topics Covered

This lecture covers a specific CIS Benchmark recommendation (18.9.70.3) for Windows 8.1 security hardening. It examines the benchmark's structure including profile applicability, description of the policy setting, recommended state, rationale for the recommendation, audit procedures, and the registry location where the setting is backed. The lecture demonstrates how to interpret and apply a single security configuration from a comprehensive 891-page security benchmark document.

📝 Lecture Summary

Topic no 78: Case Study Security Hardening – Windows 8

This section introduces the CIS Benchmarks case study specifically for Windows 8.1. The benchmark document was published on January 31, 2017 and is an extensive 891-page PDF containing hundreds of security recommendations. The lecture focuses on a single recommendation: 18.9.70.3 Ensure 'Automatically send memory dumps for OS-generated error reports' is set to 'Disabled' (Scored).

🔑 Definition — CIS Benchmarks: Consensus-based security configuration guidelines developed by the Center for Internet Security to help organizations harden their systems against attacks.

The benchmark specifies profile applicability for this recommendation—it applies to Level 1 and Level 1 + BitLocker configurations. The description explains that this policy setting controls whether memory dumps generated by the OS during error reporting are automatically sent to Microsoft.

📌 Example: A Windows 8.1 system experiences a Blue Screen of Death (BSOD). Without this policy, the memory dump containing all RAM contents (including passwords, encryption keys, and sensitive data from running applications) would automatically be uploaded to Microsoft for analysis. With the policy set to Disabled, the user or administrator must manually approve the transmission, preventing potential data leakage.

💡 Why this matters: Memory dumps are complete snapshots of system memory and can contain highly sensitive information that should never be transmitted automatically to any external party.

The rationale provided is clear: Memory dumps may contain sensitive information and should not be automatically sent to anyone. This emphasizes the security principle of data minimization and controlled disclosure.

🔑 Definition — Memory dump: A complete copy of the contents of computer memory (RAM) at the time of a system crash, which can include passwords, encryption keys, personal data, and application secrets.

The audit procedure instructs administrators to navigate to the UI Path described in the Remediation section of the benchmark to confirm the setting is applied as prescribed. The lecture notes that this group policy setting is backed by the following registry location:

• HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsError Reporting:AutoApproveOSDumps

📐 Formula: Registry Path → HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsError Reporting:AutoApproveOSDumps = 0 → Disables automatic sending of OS-generated memory dumps for error reports.

Note 1: This policy does not apply to error reports generated by 3rd-party products or additional data other than memory dumps. Note 2: The recommended state for this setting is: Disabled.

⭐ Key Takeaways

The lecture demonstrates that security hardening is a detailed, specific process involving hundreds of configuration decisions documented in comprehensive standards like CIS Benchmarks. A single security setting—disabling automatic memory dump transmission—protects against sensitive information leakage because memory dumps contain complete system memory contents including passwords and encryption keys. The setting is implemented through Group Policy and backed by a specific registry key, and administrators must verify compliance through manual audit. This case study shows how theoretical security principles translate into concrete, measurable configuration controls that can be systematically applied across an enterprise.

🧠 Quick Revision Questions

1. What is the exact CIS Benchmark recommendation number and title for the Windows 8.1 security setting discussed in this lecture?
2. Why should automatic sending of memory dumps to Microsoft be disabled from a security perspective?
3. What is the registry location that backs this Group Policy setting, and what value should the registry key have?
4. Does this policy apply to error reports generated by third-party products? What are the limits of its applicability?
5. Describe the difference between Level 1 and Level 1 + BitLocker profile applicability for this recommendation, based on what is stated in the lecture.

📘 Lecture 32 — Case Study Security Hardening – Win 10 & MS Exchange

📖 Overview: This lecture examines real-world security hardening case studies for two major Microsoft systems: Windows 10 and Exchange Server 2016. It demonstrates how to apply specific security configuration benchmarks from authoritative sources like DISA and CIS, focusing on antivirus signature updates and email database retention policies to protect against malware and data loss.

🗂️ Topics Covered

The lecture covers two case studies. First, the Windows 10 hardening case study based on DISA STIG Release 9, focusing on the requirement for daily antivirus signature updates (Rule Title, STIG ID, Severity CAT I). Second, the Microsoft Exchange Server 2016 case study based on CIS Benchmarks, focusing on the setting to not permanently delete mailbox items until the database has been backed up, including its audit and remediation via PowerShell cmdlets.

📝 Lecture Summary

Topic no 79: Case Study Security Hardening – Win 10

This case study is based on the DISA (Defense Information Systems Agency) STIG (Security Technical Implementation Guide) Release 9 (April 28, 2017) for Windows 10. The specific rule examined is: "The antivirus program must be configured to update signature files on a daily basis." The rule is identified by STIG ID: WN10-00-000046 and has a severity of CAT I (Category I, the highest severity, indicating a critical vulnerability). The discussion explains that virus scan programs are a primary line of defense against the introduction of viruses and malicious code that can destroy data and render a computer inoperable. Updated virus scan data files are essential because constantly changing malware is identified by antivirus software vendors.

🔑 Definition — STIG (Security Technical Implementation Guide): A cybersecurity methodology for standardizing security protocols within networks, servers, computers, and software, published by DISA. 🔑 Definition — CAT I (Category I): The highest severity classification for a STIG finding, indicating a vulnerability that can directly allow immediate unauthorized access to a system. 🔑 Definition — CCI (Control Correlation Identifier): A standard identifier used to map security controls across different frameworks; here CCI: 000366 maps to "The org implements the security config settings." 📐 Check Content: This requirement is Not Applicable (NA) if McAfee VirusScan Enterprise (VSE) is used, as it will be addressed with the corresponding McAfee VSE STIG. Configurations will vary depending on the product. 📐 Fix Text: Configure the antivirus program to update signature files at least daily. Ensure the updates are occurring on a timely basis and are not more than a week old. 📌 NIST References: NIST SP 800-53 :: CM-6 b; NIST SP 800-53A :: CM-6.1 (iv); NIST SP 800-53 Revision 4 :: CM-6. 💡 Why this matters: This rule is CAT I because outdated antivirus signatures can miss new malware, leaving the entire system exposed to infection and data destruction — making daily updates a critical baseline control.

Topic no 80: Case Study Security Hardening – MS Exchange

This case study is based on the CIS Benchmarks (Center for Internet Security) for MS Exchange Server 2016, a 66-page PDF document dated November 16, 2015. The specific control examined is 2.5 titled: "Set 'Do not permanently delete items until the database has been backed up' to 'True' (Scored)." The profile applicability is Level 1 - Mailbox Services Security. The description states that this setting allows you to ensure that items are not permanently deleted until the database has been backed up. The rationale is that to ensure accidentally deleted items can be recovered, they should not be permanently deleted until the database is backed up.

🔑 Definition — CIS Benchmarks: A set of globally recognized, consensus-based best practices for securely configuring IT systems, developed by the Center for Internet Security. 🔑 Definition — Scored Benchmark: A setting that contributes to a measurable security score; failing to comply reduces the overall security score of the system. 📐 Audit: Execute the following PowerShell cmdlet and ensure RetainDeletedItemsUntilBackup is set to 'True':
Get-MailboxDatabase <Mailbox Database Name> | fl -property RetainDeletedItemsUntilBackup 📐 Remediation: To implement the recommended state, execute the following PowerShell cmdlet:
Set-MailboxDatabase <Mailbox Database Name> -RetainDeletedItemsUntilBackup $true 📌 Impact: The impact of enabling this setting should be minimal. More storage space will be required until any pending items are permanently deleted. 📌 Default Value: False (items can be permanently deleted before the database backup occurs, risking permanent data loss). 💡 Why this matters: In Exchange, if an administrator or user accidentally deletes critical emails, this setting ensures those items are recoverable until a full database backup is completed — preventing irreversible data loss.

⭐ Key Takeaways

This lecture demonstrates that security hardening is applied through specific, actionable configuration rules from authoritative benchmarks like DISA STIGs and CIS Benchmarks. For Windows 10, the most critical rule (CAT I severity) is requiring daily antivirus signature updates to defend against rapidly evolving malware, with enforcement through NIST CM-6 configuration management controls. For Exchange Server 2016, a key CIS Benchmark (Level 1) is setting RetainDeletedItemsUntilBackup to True to prevent permanent deletion of mailbox items before a database backup occurs, which is audited and remediated via PowerShell cmdlets. Students must remember that hardening is not generic advice — it involves precise rule IDs (STIG ID WN10-00-000046), severity ratings (CAT I), non-applicability conditions (McAfee VSE exemption), and specific PowerShell commands for implementation and verification.

🧠 Quick Revision Questions

1. What is the STIG ID and severity level for the Windows 10 rule requiring daily antivirus signature updates?
2. Under what condition is the Windows 10 antivirus signature update rule considered "Not Applicable (NA)"?
3. What PowerShell cmdlet is used to audit whether the RetainDeletedItemsUntilBackup setting is enabled on an Exchange Server 2016 mailbox database?
4. What is the default value of the RetainDeletedItemsUntilBackup setting, and what is the rationale for changing it to True?
5. Which NIST SP 800-53 control family is referenced for the Windows 10 STIG rule, and what is the associated CCI identifier?

📘 Lecture 33 — Security Hardening – Case Study – AD

📖 Overview: This lecture examines security hardening through real-world case studies of Active Directory, Internet Explorer, Google Chrome, and Mozilla Firefox. It demonstrates how to apply DISA STIG and CIS Benchmark configurations to reduce attack surfaces and enforce security policies in enterprise environments.

🗂️ Topics Covered

The lecture covers four case studies: Active Directory Domain hardening using DISA STIG Release 8 (Topic 81), Internet Explorer 11 browser hardening using CIS Benchmarks (Topic 82), Google Chrome security configuration using DISA STIG (Topic 83), and Mozilla Firefox hardening using CIS Benchmarks (Topic 84). Each case study provides detailed rule information, check procedures, and remediation steps.

📝 Lecture Summary

Topic No 81: Security Hardening – Case Study – AD

This section presents a STIG rule for hardening Active Directory domains. The Domain Admins group is a highly privileged group that must be restricted to accounts used exclusively for managing the Active Directory domain and domain controllers. Personnel who are system administrators must log on to Active Directory systems only using accounts with the level of authority necessary. A separation of administrator responsibilities helps mitigate the risk of privilege escalation resulting from credential theft attacks. The check content requires reviewing the Domain Admins group in Active Directory Users and Computers to ensure each Domain Administrator has a separate unique account specifically for managing the domain. If any account in Domain Admins is also a member of other administrator groups (Enterprise Admins, domain member server administrators, or domain workstation administrators), this is a finding. The fix involves creating documentation identifying members and ensuring each has a separate unique account. The CCI (Control Correlation Identifier) CCI-000366 maps to NIST SP 800-53 CM-6, requiring the organization to implement security configuration settings.

🔑 Definition — STIG (Security Technical Implementation Guide): A configuration standard for Department of Defense (DoD) information assurance systems, containing rules with severity ratings (CAT I being most severe) and detailed check/fix procedures.

📐 Formula: CCI Mapping → CCI-000366 maps to NIST SP 800-53 :: CM-6 b (Configuration Management baseline)

📌 Example: Rule AD.0002: If a Domain Admin account is also a member of the Enterprise Admins group, this violates the rule and is a CAT I finding requiring immediate remediation.

Topic No 82: Case Study Security Hardening – IE Browser

This section covers CIS Benchmarks case study for Microsoft Internet Explorer 11 from January 12, 2014 (178-page PDF doc). The specific rule is "1.5 Configure 'Do not allow users to enable or disable add-ons' (Not Scored)". This policy setting allows management of whether users can allow or deny add-ons through Add-On Manager. If enabled, users cannot enable or disable add-ons through Add-On Manager, except for add-ons specifically entered into the 'Add-On List' policy setting that allows user management. If disabled or not configured, appropriate controls in Add-On Manager are available to users. The rationale states that users often choose to install add-ons not permitted by an organization's security policy, which can pose significant security and privacy risks. The audit checks the registry key HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\InternetExplorer\Restrictions\NoExtensionManagement. Remediation via Group Policy sets the UI path to Not Configured: Computer Configuration\Administrative Templates\Windows Components\Internet Explorer\Do not allow users to enable or disable add-ons. The default value is Disabled.

🔑 Definition — CIS Benchmark: Consensus-based security configuration guidelines developed by the Center for Internet Security for hardening operating systems, applications, and network devices.

📌 Example: If an organization enables the "Do not allow users to enable or disable add-ons" policy, employees cannot install unauthorized browser extensions like toolbars or plugins that might exfiltrate data.

💡 Why this matters: Browser add-ons are a common attack vector; controlling them prevents drive-by downloads and data theft through malicious extensions.

Topic No 83: Security Hardening – Case Study – Chrome

This section covers Google Chrome hardening using DISA STIG Release 8 (April 27, 2017). The rule title is "Session only based cookies must be disabled" (Vuln ID: V-44799, STIG ID: DTBC-0045, Severity: CAT I). The policy allows setting a list of URL patterns specifying sites allowed to set session-only cookies. If this policy is left not set, the global default value from the 'DefaultCookiesSetting' policy or user's personal configuration will be used for all sites. If the 'RestoreOnStartup' policy is set to restore URLs from previous sessions, this policy will not be respected and cookies will be stored permanently for those sites. The check content has a universal method: in omnibox type chrome://policy and verify if the policy CookiesSessionOnlyForUrls exists with any defined values — this is a finding. Windows method involves navigating registry to HKLM\Software\Policies\Google\Google Chrome\Content Settings\CookiesSessionOnlyForUrls. The fix via Windows group policy sets: Policy Path Computer Configuration\Administrative Templates\Google\Google Chrome\Content Settings, Policy Name "Allow session only cookies on these sites", Policy State: Disabled, Policy Value: N/A. The CCI-000166 maps to NIST SP 800-53 AU-10 (non-repudiation), protecting against individuals falsely denying having performed organization-defined actions.

🔑 Definition — Session-only cookies: Temporary cookies that are deleted when the browser session ends, preventing persistent tracking across browsing sessions.

📌 Example: If an organization disables session-only cookies for all sites, users cannot bypass cookie policies, ensuring all websites store cookies permanently as per organizational security requirements, preventing non-repudiation issues.

Topic No 84: Case Study Security Hardening – Firefox

This section covers CIS Benchmarks case study for Mozilla Firefox from December 31, 2015 (72-page PDF doc). The rule is "3.5 (L2) Enable IDN Show Punycode (Scored)" at Level 2. This feature determines whether all Internationalized Domain Names (IDNs) displayed in the browser are displayed as Punycode or as Unicode. The rationale states that IDNs displayed in Punycode are easier to identify and therefore help mitigate the risk of accessing spoofed web pages. The audit procedure involves: typing about:config in the address bar, typing network.IDN_show_punycode in the filter, and ensuring the preference is set to true. The remediation involves opening the mozilla.cfg file in the installation directory and adding the line: lockPref("network.IDN_show_punycode", true);. The default value is false.

🔑 Definition — Punycode: A standardized encoding system used to represent Internationalized Domain Names (IDNs) in ASCII characters, making visually similar characters (homoglyphs) distinguishable.

📌 Example: A malicious site might use Cyrillic "а" (U+0430) instead of Latin "a" in "apple.com" to create "арple.com". Punycode encoding shows xn--pple-43d.com instead, making the spoofing attempt obvious.

💡 Why this matters: Homograph attacks use visually identical characters from different scripts to create lookalike domains. Punycode display prevents users from being tricked into visiting fake websites.

⭐ Key Takeaways

Security hardening must be applied systematically across all enterprise components, from Active Directory to browsers. The Domain Admins group must contain only accounts dedicated exclusively to domain management, with strict separation of duties to prevent privilege escalation. Browser hardening controls (add-ons, cookies, and domain display) are critical because browsers are primary attack surfaces for credential theft and malware delivery. STIG rules and CIS Benchmarks provide standardized, auditable configurations with clear severity ratings, check procedures, and remediation steps. Understanding the CCI mapping to NIST SP 800-53 controls helps align hardening with broader compliance frameworks.

🧠 Quick Revision Questions

1. What is the severity rating of STIG rule AD.0002, and what specific violation does it address regarding Domain Admins group membership?
2. How does enabling the IE "Do not allow users to enable or disable add-ons" policy help mitigate security risks from browser extensions?
3. What is the registry path to audit the Chrome "CookiesSessionOnlyForUrls" policy on Windows systems?
4. Why does enabling Punycode display (network.IDN_show_punycode=true) in Firefox help prevent spoofing attacks?
5. What is the CCI identifier for the Chrome rule DTBC-0045, and which NIST SP 800-53 control does it map to?

📘 Lecture 34 — Security Hardening – Case Study – FW

📖 Overview: This lecture examines a specific case study in security hardening by analyzing a Firewall STIG (Security Technical Implementation Guide) from DISA. It demonstrates how to read and apply STIG requirements to protect a network against common denial-of-service attacks, using real-world vulnerability identifiers and remediation steps.

🗂️ Topics Covered

The lecture examines the DISA Firewall STIG, Release 22, dated 28 April 2017, using the STIGViewer window. It details a specific rule (Rule Title, Vuln ID, STIG ID, Severity) requiring protection against denial of service attacks. The discussion explains SYN-flood attacks and ping sweeps, then covers check content for verifying compliance and fix text for remediation.

📝 Lecture Summary

STIGVIEWER WINDOW

General Information

The lecture presents a specific firewall STIG rule. The Rule Title states: "The device must be configured to protect the network against denial of service attacks such as Ping of Death, TCP SYN floods, etc." The Vuln ID is V-3156, the STIG ID is NET0375, and the Severity is CAT II (meaning a significant risk that requires attention but is not catastrophic).

🔑 Definition — STIG (Security Technical Implementation Guide): A standardized security configuration document from DISA (Defense Information Systems Agency) that specifies hardening requirements for devices and systems. 💡 Why this matters: STIGs are the authoritative source for securing government and military systems, and their principles apply broadly to enterprise security.

Discussion

The discussion section explains two attack types. A SYN-flood attack is a denial-of-service attack where the attacker sends a huge number of "please-start-a-connection" packets (TCP SYN packets) and then nothing else. This causes the attacked device to be overloaded with open sessions pending completion of the three-way handshake, eventually causing it to crash. A ping sweep (also known as an ICMP sweep) is a basic network scanning technique used to determine which of a range of IP addresses map to live hosts (computers) by sending ICMP echo requests.

Check Content

The Check Content provides the verification procedure. It instructs: "Review the device configurations to determine if denial of service attacks are guarded against. If the device is not configured to mitigate denial of service attacks, this is a finding."

📌 Example: An auditor reviews a firewall's configuration. They find no SYN flood protection or ICMP rate-limiting enabled. According to the check content, this is a "finding" (a non-compliance issue that must be documented and fixed).

Fix Text

The Fix Text provides the remediation steps. It states: "If the firewall supports SYN-flood or ping sweep protection then enable these features. If the firewall does not support these features, enable the security features on the router to protect the network from these attacks."

📌 Example: A system administrator looks at the firewall's capabilities. If it has a "SYN flood protection" toggle, they enable it. If the firewall lacks this feature, they go to the network router and enable TCP intercept or similar router-based protection.

CCI (Control Correlation Identifier)

The lecture notes CCI as "Misc info" — meaning it provides a cross-reference to a master control catalog used for compliance tracking, but the specific details are beyond the scope of this lecture.

⭐ Key Takeaways

A STIG rule is structured into five critical sections: General Information (Rule Title, Vuln ID, STIG ID, Severity), Discussion, Check Content, Fix Text, and CCI. Severity levels (like CAT II) indicate the criticality of the vulnerability, driving prioritization for remediation. The Check Content tells you exactly what to verify, while Fix Text gives you the exact steps to resolve non-compliance. When a firewall lacks native protection (e.g., against SYN floods or ping sweeps), the solution is to enable equivalent security features on an upstream router. Understanding these five sections enables a security professional to read, interpret, and implement any STIG requirement systematically.

🧠 Quick Revision Questions

1. What are the five standard sections of a STIG rule as shown in this lecture?
2. What is the difference between a SYN-flood attack and a ping sweep?
3. According to the Fixed Text, what should you do if the firewall does not support SYN-flood protection?
4. What does a "finding" mean in the context of Check Content?
5. What does the severity "CAT II" indicate about the importance of this rule?

Here is the summary for Lecture 35 based on your text, following the exact format you provided.

📘 Lecture 35 — Security Hardening – Case Study – Switch

📖 Overview: This lecture examines a specific case study from the DISA STIG (Security Technical Implementation Guide) for Layer 2 switches. It focuses on a critical port security rule that requires a switchport to shut down upon detecting a MAC address violation, explaining the vulnerability, the required configuration, and the severity of non-compliance.

🗂️ Topics Covered

The lecture covers the specifics of a single STIG rule from the "Layer 2 Switch STIG, DISA, Release 20, 28 Oct 2016". It details the rule's title, vulnerability ID, STIG ID, and severity rating of CAT III. It also includes a discussion of the Port Security feature's behavior, the required "shutdown" action for violations, and the specific Cisco IOS command to implement this security hardening measure.

📝 Lecture Summary

[No Section Heading Provided - Content is the lecture itself]

The lecture presents a case study based on a specific rule from the DISA STIG. The IAO (Information Assurance Officer) is responsible for ensuring all switchports are configured with MAC port security. The key requirement is that the switchport must be configured to shutdown upon receiving a frame with a layer 2 source address that does not match the configured or dynamically learned address. This is identified as Vuln ID: V-18565 and STIG ID: NET-NAC-032, with a severity of CAT III (Category III).

The Port Security feature functions by remembering the Ethernet MAC address connected to a specific switch port. It then restricts communication on that port exclusively to that MAC address. If any other MAC address attempts to communicate through the port, port security disables the port by placing it in an error-disabled state and sending an SNMP trap notification.

💡 Why this matters: This rule is a direct defense against MAC address flooding attacks and unauthorized device connections. By forcing the switchport to "shutdown" on a violation, it immediately stops the attack or unauthorized access, providing a robust security boundary.

🔑 Definition — Port Security: A switch feature that restricts input to an interface by limiting and identifying the MAC addresses of the stations allowed to access the port. 🔑 Definition — DISA STIG: The Defense Information Systems Agency Security Technical Implementation Guide; a standard for securing information systems and networks. 🔑 Definition — CAT III (Category III): A severity classification in the STIG framework for vulnerabilities that result in the loss of confidentiality, availability, or integrity, but are not considered as critical as CAT I or II. 📐 Required Action/Command: switchport port-security violation shutdown → This specific interface command forces the switchport to enter the error-disabled state and send an SNMP trap if it receives a frame with a source MAC address that violates the port's configured security settings. 📌 Example: A network administrator configures port security on interface Gi0/1, manually specifying the allowed MAC address as aaaa.bbbb.cccc. If an attacker connects a device with MAC address 1111.2222.3333 and sends a frame, the switch will place Gi0/1 into an error-disabled state and send an SNMP trap to the network management system. The port will remain down until manually re-enabled by an administrator.

⭐ Key Takeaways

A student must remember that this lecture details a specific STIG rule requiring a "shutdown" action for MAC port security violations on switchports. This is a network hardening technique that defends against MAC address flooding and unauthorized device access. The core command is switchport port-security violation shutdown, which immediately places the port in an error-disabled state and sends an SNMP trap. This action is classified as a CAT III vulnerability if not implemented, meaning it has a moderate impact on security. The ultimate goal is to ensure that only authorized MAC addresses can communicate through a given switchport.

🧠 Quick Revision Questions

1. What is the specific action that the STIG rule V-18565 requires a switch to take when a MAC address violation occurs? (The switchport must shutdown/place the interface into an error-disabled state.)
2. What is the exact Cisco IOS command used to configure this security hardening rule? (switchport port-security violation shutdown)
3. What two actions does the switch perform when a port violation occurs under this configured rule? (It places the interface into the error-disabled state and sends an SNMP trap notification.)
4. What is the primary purpose of configuring MAC port security on a switchport? (To remember the Ethernet MAC address connected to the port and allow only that address to communicate.)
5. What is the severity level (Category) assigned to this STIG rule (NET-NAC-032)? (CAT III)

📘 Lecture 36 — Case Study Security Hardening – Cisco IOS 15

📖 Overview: This lecture examines the CIS Benchmark case study for Cisco IOS 15 routers, focusing on security hardening recommendations. It demonstrates how to apply specific configuration controls—such as OSPF MD5 authentication—to enforce enterprise security policies and protect routing protocol exchanges between network devices.

🗂️ Topics Covered

The lecture first discusses a fix text for configuring a port to shut down when insecure hosts are connected. It then presents Topic No 87: Case Study Security Hardening – Cisco IOS 15, covering the CIS Benchmarks case study for Cisco routers running IOS 15M. The main content details the specific benchmark 3.3.2.2, which requires setting 'ip ospf message-digest-key md5' as a scored configuration item, including its profile applicability, description, rationale, audit procedure, remediation steps, impact, and default value.

📝 Lecture Summary

Fix Text

Configure the port to shutdown when insecure hosts are connected to the wall jack.

Topic No 87: Case Study Security Hardening – Cisco IOS 15

This section introduces a case study on security hardening for Cisco routers running IOS 15M based on the CIS Benchmarks document dated June 30, 2015 (151 pages PDF). The focus is on a specific benchmark item: 3.3.2.2 Set 'ip ospf message-digest-key md5' (Scored).

🔑 Definition — CIS Benchmark: A set of security configuration guidelines published by the Center for Internet Security for hardening systems.

The benchmark specifies:

• Profile applicability: Level 2
• Description: Enable Open Shortest Path First (OSPF) Message Digest 5 (MD5) authentication.
• Rationale: This is part of the OSPF authentication setup.
• Audit: Verify the appropriate MD5 key is defined on the appropriate interface(s) using the command: hostname#sh run int {interface}
• Remediation: Configure the appropriate interface(s) for Message Digest authentication using:
  • hostname(config)#interface {interface_name}
  • hostname(config-if)#ip ospf message-digest-key {ospf_md5_key-id} md5 {ospf_md5_key}
• Impact: Organizations should plan and implement enterprise security policies that require rigorous authentication methods for routing protocols. Configuring the proper interface(s) for 'ip ospf message-digest-key md5' enforces these policies by restricting exchanges between network devices.
• Default Value: Not set

💡 Why this matters: OSPF authentication prevents unauthorized routers from injecting false routing information into the network, which could cause traffic redirection, denial of service, or man-in-the-middle attacks.

⭐ Key Takeaways

Students must remember that the CIS Benchmark for Cisco IOS 15 provides scored security hardening recommendations, with benchmark 3.3.2.2 specifically requiring OSPF MD5 authentication on router interfaces. The default value for OSPF MD5 authentication is not set, meaning routers are vulnerable unless explicitly configured. The remediation involves two commands on the appropriate interface: one to enter interface configuration mode, and one to set the MD5 key with an ID and key value. The audit command verifies the configuration by showing the running interface configuration. This hardening measure enforces enterprise security policies by authenticating routing protocol exchanges between network devices.

🧠 Quick Revision Questions

1. What is the exact CIS benchmark number for requiring OSPF MD5 authentication in the Cisco IOS 15 case study?
2. What is the default value for 'ip ospf message-digest-key md5' on a Cisco IOS 15 router?
3. What two commands are needed to configure OSPF MD5 authentication on a Cisco interface?
4. How can an administrator verify that the appropriate OSPF MD5 key is configured on an interface?
5. Why does the CIS benchmark recommend configuring OSPF MD5 authentication rather than leaving it unset?

📘 Lecture 37 — Security Hardening – Case Study – WLAN

📖 Overview: This lecture examines real-world security hardening case studies for WLAN controllers, Layer 3 switches, and VMware ESXi hosts. By analyzing STIG and CIS benchmark requirements, students learn how to apply hardening principles to specific technologies, including authentication protocols and service configurations.

🗂️ Topics Covered

The lecture covers three security hardening case studies: WLAN Controller STIG requiring EAP-TLS authentication; Infrastructure Layer 3 Switch STIG requiring L2TPv3 session authentication; and CIS Benchmark for VMware ESXi 5.5 focusing on disabling the Direct Console User Interface (DCUI) to enforce centralized management through vCenter.

📝 Lecture Summary

Topic No 88: Security Hardening – Case Study – WLAN

The WLAN Controller STIG from DISA, Release 12 (dated 28 Oct, 2016) mandates that WLAN must use EAP-TLS (Rule Title). This rule has Vuln ID V-3692, STIG ID WIR0115-01, and Severity CAT II.

🔑 Definition — EAP-TLS (Extensible Authentication Protocol - Transport Layer Security): a strong cryptographic protocol providing mutual authentication and key distribution services that protect against attacks more effectively than other EAP methods.

The Discussion explains that EAP-TLS provides strong cryptographic mutual authentication and key distribution services not found in other EAP methods, offering significantly more protection against attacks. Additionally, EAP-TLS supports two-factor user authentication on the WLAN client, providing more protection than password-only or certificate-only methods. EAP-TLS can also leverage DoD CAC (Common Access Card) for authentication services, adding security and convenience.

The Check Content states that if equipment is WPA2 certified, it is capable of supporting this requirement. Review the WLAN equipment configuration to verify EAP-TLS is actively used and no other methods are enabled. Mark as a finding if EAP-TLS is not used or if the WLAN system allows users to connect with other methods.

The Fix Text requires changing the WLAN configuration to support EAP-TLS, implementing supporting PKI and AAA infrastructure as necessary. If equipment cannot support EAP-TLS, procure new equipment capable of such support.

💡 Why this matters: EAP-TLS is the gold standard for wireless authentication in secure environments because it combines mutual authentication, encryption, and support for hardware tokens like CAC cards.

Topic No 89: Security Hardening – Case Study – L3 Switch

The Infrastructure Layer 3 Switch STIG from DISA, Release 22 (dated 28 April, 2017) mandates that the administrator must ensure all L2TPv3 sessions are authenticated prior to transporting traffic (Rule Title). This rule has Vuln ID V-30744, STIG ID NET-TUNL-034, and Severity CAT II.

🔑 Definition — L2TPv3 (Layer 2 Tunneling Protocol Version 3): a protocol used to transport layer-2 protocols across an IP backbone, where these layer-2 protocols were originally intended for link-local scope only.

The Discussion notes that L2TPv3 sessions can transport layer-2 protocols across an IP backbone, but these protocols were intended for link-local scope only and are therefore less defended and less well-known. As stated in DoD IPv6 IA Guidance for MO3 (S4-C7-1), L2TP tunnels can carry IP packets that are very difficult to filter because of additional encapsulation. Hence, it is imperative that L2TP sessions are authenticated before transporting traffic.

The Check Content requires reviewing the router or multi-layer switch configuration to determine if L2TPv3 has been configured to provide transport across an IP network. If configured, verify that the L2TPv3 session requires authentication.

The Fix Text requires configuring L2TPv3 to use authentication for any peering sessions.

💡 Why this matters: Without authentication, L2TPv3 tunnels can be exploited to bypass network filters, allowing malicious traffic to traverse the network undetected through encapsulation.

Topic No 90: Case Study Security Hardening – VMware

The CIS Benchmark case study for VMware ESXi 5.5 (dated December 16, 2014, 132 pages) covers rule 5.1: Disable DCUI to prevent local administrative control (Scored).

Profile applicability: Level 2

🔑 Definition — DCUI (Direct Console User Interface): the local management interface on an ESXi host that allows low-level configuration such as IP address, hostname, and root password, as well as diagnostic capabilities.

Description: The DCUI can be disabled to prevent any local administration from the Host. Once the DCUI is disabled, all administration of the ESXi host will be done through vCenter.

Rationale: The DCUI allows low-level host configuration (IP address, hostname, root password) and diagnostic capabilities (enabling ESXi shell, viewing log files, restarting agents, resetting configurations). Actions performed from the DCUI are not tracked by vCenter Server. Even if Lockdown Mode is enabled, users who are members of the DCUI.Access list can perform actions not tracked in vCenter Server, where actions can be centrally audited and monitored.

Audit procedure:

1. From vSphere web client, select the host
2. Select "Manage" → "Settings" → "System" → "Security Profile"
3. Scroll down to "Services"
4. Click "Edit..."
5. Select "Direct Console UI"
6. Verify the Startup Policy is set to "Start and Stop Manually"

Additionally, use PowerCLI command: Get-VMHost | Get-VMHostService | Where { $_.key -eq "DCUI" }

Remediation:

1. From vSphere web client, select the host
2. Select "Manage" → "Settings" → "System" → "Security Profile"
3. Scroll down to "Services"
4. Click "Edit..."
5. Select "Direct Console UI"
6. Click "Stop"
7. Change the Startup Policy to "Start and Stop Manually"
8. Click "OK"

Impact: Disabling the DCUI can create a potential "lock out" situation if the host becomes isolated from vCenter Server. Recovering from a "lock out" scenario requires re-installing ESXi. Consider leaving DCUI enabled and instead enable lockdown mode, limiting users allowed to access DCUI using the DCUI.Access list.

Default Value: The prescribed state (DCUI disabled) is not the default state.

💡 Why this matters: Centralized management through vCenter ensures all administrative actions are logged and audited, preventing unauthorized or untracked changes at the host level.

⭐ Key Takeaways

The lecture demonstrates three critical security hardening requirements: WLAN controllers must enforce EAP-TLS with mutual authentication and support for DoD CAC; Layer 3 switches must authenticate all L2TPv3 sessions before transporting traffic to prevent encapsulation-based attacks; and VMware ESXi hosts should disable DCUI to force administrative actions through vCenter for centralized auditing, while being aware of the lock-out risk. These case studies illustrate how DISA STIGs and CIS Benchmarks provide specific, actionable configuration requirements for different infrastructure components.

🧠 Quick Revision Questions

1. What are the three security benefits of EAP-TLS over other EAP methods for WLAN authentication?
2. Why must L2TPv3 sessions be authenticated before transporting traffic according to the STIG?
3. What is the rule title, vulnerability ID, and STIG ID for the WLAN STIG requiring EAP-TLS?
4. What is the potential impact of disabling DCUI on an ESXi host, and what alternative approach does the benchmark suggest?
5. How can administrators audit whether DCUI is properly disabled on an ESXi host using both the vSphere web client and PowerCLI?

📘 Lecture 38 — Software Security Fundamentals - SAMM & SAMM-2

📖 Overview: This lecture introduces the OWASP Software Assurance Maturity Model (SAMM) as a structured framework for building security into software development. It covers the Governance and Construction phases in detail, then shifts to a practical 8-step methodology for security hardening of software applications. Understanding SAMM is essential for establishing a measurable, risk-aligned software security assurance program.

🗂️ Topics Covered

The lecture examines the OWASP Software Assurance Maturity Model (SAMM), focusing on its Governance Phase (Strategy & Metrics, Education & Guidance, Policy & Compliance) and Construction Phase (Security Requirements, Threat Assessment, Secure Architecture). It then transitions to security hardening of software applications, detailing an 8-step security hardening methodology and listing key resources such as OWASP, Cloud Security Alliance, and MS Technet.

📝 Lecture Summary

Topic no 91 & 92: Software Security Fundamentals-SAMM & SAMM-2

The Software Assurance Maturity Model (SAMM) was developed by OWASP (Open Web Application Security Project) as a guide to building security into software development. It is a comprehensive 96-page PDF document that provides a structured framework. The model is organized into phases, each containing specific practices to improve software security.

🔑 Definition — SAMM (Software Assurance Maturity Model): A framework by OWASP that provides a guide to building security into software development, organized into phases and practices. 💡 Why this matters: SAMM gives organizations a measurable way to evaluate and improve their software security posture, aligning security goals with business risk.

Topic no 92: OWASP Software Assurance Maturity Model (SAMM) Governance Phase

The Governance Phase of SAMM focuses on establishing the organizational framework for a software security assurance program. It includes three key practices:

• Strategy & Metrics: This practice is focused on establishing the framework within an organization for a software security assurance program. It is the most fundamental step in defining security goals in a way that is both measurable and aligned with the organization's real business risk.

• Education & Guidance: This practice is focused on arming personnel involved in the software lifecycle with knowledge and resources to design, develop, and deploy secure software. With improved access to information, project teams will be better able to proactively identify and mitigate the specific security risks that apply to their organization.

• Policy & Compliance: This practice is focused on understanding and meeting external legal and regulatory requirements while also driving internal security standards to ensure compliance in a way that is aligned with the business purpose of the organization. A driving theme for improvement within this Practice is focus on project-level audits that gather information about the organization's behavior to check that expectations are being met.

Topic no 93: OWASP Software Assurance Maturity Model (SAMM) Construction Phase

The Construction Phase of SAMM focuses on secure software development activities. It includes three key practices:

• Security Requirements: This practice is focused on proactively specifying the expected behavior of software with respect to security. Through the addition of analysis activities at the project level, security requirements are initially gathered based on the high-level business purpose of the software.

• Threat Assessment: This practice is centered on identification and understanding of project-level risks based on the functionality of the software being developed and characteristics of the runtime environment. From details about threats and likely attacks against each project, the organization as a whole operates more effectively through better decisions about prioritization of initiatives for security.

• Secure Architecture: This practice is focused on proactive steps for an organization to design and build secure software by default. By enhancing the software design process with reusable services and components, the overall security risk from software development can be dramatically reduced.

SAMM is an excellent model for software security and we look at the Verification and Deployment phases as part of testing and validation, though they are not detailed in this lecture.

Topic no 94: SECURITY HARDENING – SOFTWARE APPLICATIONS

Security hardening applies to two types of assets: IT assets (systems, network devices, databases, applications) and software developed internally or by a third party. Typical enterprise software includes ERP systems (Oracle, SAP, IBM, etc.) and internally or third-party developed software in ASP.NET, PHP, Android/IOS, or other platforms.

An 8-step security hardening methodology is presented as a structured approach to securing software applications. Useful resources for security hardening include:

• www.OWASP.org
• www.cloudsecurityalliance.org
• MS Technet
• OWASP Top 10
• OWASP Secure Coding Practices Quick Reference Guide
• SAMM

Conclusion: Software security hardening is a challenging activity. Organizations should build a software security program and integrate it with QA, acquire domain-specific knowledge, and build capabilities and processes following SAMM.

⭐ Key Takeaways

The most critical concepts from this lecture are that SAMM provides a comprehensive, phased framework for building security into software development, with the Governance Phase establishing organizational strategy, education, and compliance, and the Construction Phase focusing on requirements, threat assessment, and architecture. Security hardening is a separate but complementary activity that applies to both IT assets and developed software, following a structured 8-step methodology. For exams, remember the three practices in the Governance Phase (Strategy & Metrics, Education & Guidance, Policy & Compliance) and the three practices in the Construction Phase (Security Requirements, Threat Assessment, Secure Architecture), along with the definition and purpose of SAMM.

🧠 Quick Revision Questions

1. What does SAMM stand for, and which organization developed it?
2. List the three practices in the Governance Phase of SAMM.
3. What is the primary focus of the "Strategy & Metrics" practice in SAMM?
4. Identify the three practices in the Construction Phase of SAMM.
5. What are the two types of assets that security hardening applies to?

📘 Lecture 39 — CASE STUDY – ASP.NET SECURITY HARDENING

📖 Overview: This lecture examines security hardening practices for various web application frameworks through case studies. It covers ASP.NET Web Forms and MVC security guidance, PHP security hardening, and SharePoint STIG (Security Technical Implementation Guide) compliance, providing practical configuration recommendations to protect against common threats.

🗂️ Topics Covered

The lecture covers OWASP ASP.NET Cheat Sheet guidance including .NET Framework data access and general guidance, ASP.NET Web Forms settings, and ASP.NET MVC security based on OWASP Top 10. It then examines PHP security hardening covering XSS, injections (SQL, directory traversal, command, code), CSRF, public files, passwords, file uploads, session hijacking, remote file inclusion, PHP configuration (error reporting, version exposure, open_basedir, session settings), and HTTPS. Finally, it covers SharePoint 2013 STIG requirements, specifically the rule that Central Administration must not be installed in the DMZ for Internet-facing environments.

📝 Lecture Summary

Topic no 95: CASE STUDY – ASP.NET SECURITY HARDENING

The lecture begins with the OWASP ASP.NET Cheat Sheet as a primary reference for securing .NET applications. It provides specific guidance for three areas: .NET Framework, ASP.NET Web Forms, and ASP.NET MVC.

.NET Framework, Data Access Guidance For all data access, you must use Parameterized SQL commands without exception. Do not use SqlCommand with a string parameter made from concatenated SQL strings. Whitelist allowable values from users using enums, TryParse, or lookup values. Apply the principle of least privilege for database users. Using Entity Framework is an effective SQL injection prevention mechanism. When using SQL Server, prefer integrated authentication over SQL authentication. Use Always Encrypted where possible for sensitive data (SQL Server 2016 and SQL Azure).

🔑 Definition — Parameterized SQL: SQL commands where parameters are passed separately from the SQL statement, preventing malicious code injection. 📐 Formula: Parameterized SQL → Database treats input as data, not executable code. 📌 Example: Instead of "SELECT * FROM Users WHERE Name = '" + userName + "'", use SqlCommand cmd = new SqlCommand("SELECT * FROM Users WHERE Name = @UserName", connection); cmd.Parameters.AddWithValue("@UserName", userName);

.NET Framework, General Guidance You must lock down the config file and remove all unused configuration aspects. Encrypt sensitive parts of web.config using aspnet_regiis -pe. For Click Once applications, upgrade to .NET Framework version 4.6.2 to ensure TLS 1.1/1.2 support.

🔑 Definition — aspnet_regiis -pe: A command-line tool for encrypting sections of the web.config file, such as connection strings and app settings. 💡 Why this matters: If an attacker gains file access, encrypted config sections prevent exposure of database passwords, API keys, and other secrets.

ASP.NET Web Forms Guidance Web Forms guidance includes HTTPS and general configuration, HTTP validation & encoding, and Forms authentication settings.

ASP.NET MVC Guidance ASP.NET MVC (Model-View-Controller) is a contemporary web application framework that uses more standardized HTTP communication than Web Forms postback. Its security approach is based on OWASP Top 10.

Topic no 96: CASE STUDY – PHP SECURITY HARDENING

PHP security guidelines from https://docs.php.earth/security/intro/ cover 11 threat categories:

1. Cross site scripting (XSS)
2. Injections – SQL injection, Directory traversal (path injection), Command injection, Code injection
3. Cross site request forgery (XSRF/CSRF)
4. Public files
5. Passwords
6. Uploading files
7. Session hijacking
8. Remote file inclusion
9. PHP configuration – Error reporting, Exposing PHP version, Remote files, Open_basedir, Session settings
10. Use HTTPS
11. Things not listed

PHP Configuration Always keep the installed PHP version updated using versionscan to check for vulnerabilities. Update open source libraries and applications. Important php.ini settings include:

• Error Reporting: In production, always turn off displaying errors to the screen. If errors are visible to the outside world, an attacker could get valuable data for attacking your application.

🔑 Definition — versionscan: A tool to check your PHP version for known vulnerabilities. 💡 Why this matters: Error messages often reveal database structure, file paths, and stack traces that attackers use to craft targeted exploits.

Topic no 97: CASE STUDY – ASP.NET MVC SECURITY HARDENING

ASP.NET MVC uses more standardized HTTP communication than Web Forms. The OWASP Top 10 lists the most prevalent and dangerous threats, reviewed every 3 years. Your approach should start at the top threat (A1) and work down to cover threats most effectively.

A.6 Sensitive data exposure

DO NOT: Store encrypted passwords. DO: Use a strong hash (PBKDF2, BCrypt, or SCrypt with at least 8000 iterations and a strong key) to store password credentials. DO: Enforce passwords with minimum complexity to survive dictionary attacks – longer passwords using the full character set (numbers, symbols, letters) to increase entropy. DO: Use a strong encryption routine such as AES-512 for personally identifiable data that needs restoration. Do not encrypt passwords. Protect encryption keys more than any other asset. DO: Apply the test: Would you be happy leaving the data on a spreadsheet on a bus for everyone to read? Assume the attacker can get direct access to your database. DO: Use TLS 1.2 for your entire site. Get a free certificate from StartSSL.com or LetsEncrypt.org. DO NOT: Allow SSL – it is now obsolete. DO: Have a strong TLS policy (see SSL Best Practices), use TLS 1.2 wherever possible. Check configuration using SSL Test. DO: Ensure headers are not disclosing information about your application (see HttpHeaders.cs, Dionach StripHeaders, or disable via web.config).

🔑 Definition — PBKDF2: Password-Based Key Derivation Function 2, a key stretching algorithm that makes brute-force attacks computationally expensive. 📐 Formula: Hash = PBKDF2(password, salt, iterations ≥ 8000, key length) → Computationally slow hash resistant to GPU attacks.

Topic no 98: Security Hardening – Case Study-SharePoint

SharePoint 2013 STIG (Security Technical Implementation Guide) from DISA, Release 3, dated 22 April 2016, covers SharePoint server side configurations.

General Information:

• Rule Title: For environments requiring an Internet-facing capability, the SharePoint application server upon which Central Administration is installed, must not be installed in the DMZ.
• Vuln ID: V-59995
• STIG ID: SP13-00-000155
• Severity: CAT II

Discussion: Information flow control regulates where information is allowed to travel within an information system. SharePoint Central Administration is a powerful management tool used to administer the farm. This server should be installed on a trusted network segment and used to run services rather than user-oriented web applications.

Check Content: For environments requiring an Internet-facing capability, ensure the SharePoint Central Administration application server is not in the DMZ. Inspect the logical location of the server farm web front end servers. Verify the Central Administration site is not installed on a server located in a DMZ or other publicly accessible segment. If Central Administration is installed on a publicly facing SharePoint server, this is a finding.

Fix Text: For environments requiring an Internet-facing capability, remove the SharePoint Central Administration application server from the DMZ.

🔑 Definition — STIG (Security Technical Implementation Guide): A cybersecurity methodology for standardizing security protocols within networks, servers, computers, and software developed by DISA. 💡 Why this matters: Central Administration access from the DMZ could allow an attacker to take complete control of the entire SharePoint farm.

⭐ Key Takeaways

The most critical security practices covered include: always using parameterized SQL queries to prevent injection attacks; encrypting web.config sections and never storing passwords in reversible encryption (use strong hashing with sufficient iterations); disabling error display in production environments to prevent information leakage; using HTTPS with TLS 1.2+ exclusively and avoiding obsolete SSL; and ensuring sensitive administrative services like SharePoint Central Administration remain on trusted internal networks, never in the DMZ.

🧠 Quick Revision Questions

1. What is the correct method for database access in .NET Framework according to OWASP guidance, and why?
2. What command encrypts sensitive parts of web.config, and what tool checks PHP version vulnerabilities?
3. What is the minimum iteration count recommended for PBKDF2/BCrypt/SCrypt password hashing?
4. Why must SharePoint Central Administration not be installed in the DMZ for Internet-facing environments?
5. What is the difference between hashing and encrypting passwords, and which should be used for each?

📘 Lecture 40 — CASE STUDY – C APPLICATIONS SECURITY HARDENING

📖 Overview: This lecture examines the SEI CERT C Coding Standard, focusing on the dangers of casting away const qualification in C applications. It explains why modifying const-qualified objects leads to unsafe behavior and how to avoid such vulnerabilities in secure coding practices.

🗂️ Topics Covered

The lecture covers the SEI CERT C Coding Standard from Carnegie Mellon Software Engineering Institute, the problem of casting away const qualification, unsafe assignments allowing modification of constant objects, compliant solutions based on programmer intent, and risk assessment and automated detection of this vulnerability.

📝 Lecture Summary

Topic no 99: CASE STUDY – C APPLICATIONS SECURITY HARDENING

The lecture references the Carnegie Mellon Software Engineering Institute and the SEI CERT C Coding Standard. These standards provide guidelines for secure coding in C to prevent common vulnerabilities.

🔑 Definition — const-qualified object: An object declared with the const keyword in C, indicating its value should not be changed after initialization.

📌 Example of unsafe casting: There are existing compiler implementations that allow const-qualified objects to be modified without generating a warning message. This is dangerous because it circumvents the protection intended by the const qualifier.

The standard explicitly states: Avoid casting away const qualification because doing so makes it possible to modify const-qualified objects without issuing diagnostics.

📌 Example of noncompliant code:
The first assignment described is unsafe because it allows the code that follows it to attempt to change the value of the const object i. When a const object is modified through a cast that removes its constness, the behavior is undefined.

The compliant solution depends on the intent of the programmer:

• If the intent is that the value of i is modifiable, then it should not be declared as a constant.
• If the intent is that the value of i is not meant to change, then do not write noncompliant code that attempts to modify it.

🔑 Definition — Risk Assessment: The process of evaluating the severity and likelihood of vulnerabilities. For this issue, the standard provides automated detection methods and catalogs related vulnerabilities.

💡 Why this matters: Modifying const objects can lead to undefined behavior, memory corruption, or security exploits in production code. Proper use of const ensures both code correctness and security.

⭐ Key Takeaways

The most critical takeaway is that casting away const qualification in C is inherently dangerous and should always be avoided. Programmers must clearly decide whether a variable should be constant or mutable at declaration time — never attempt to modify a const object through pointer casts. The SEI CERT C Coding Standard provides authoritative guidelines for this and other secure coding practices. Automated detection tools exist to catch such violations, and developers should use them in their build pipelines. Understanding the intent of the programmer is key to choosing the correct solution.

🧠 Quick Revision Questions

1. Why is it unsafe to cast away const qualification from a const-qualified object?
2. What two possible intents should a programmer consider when writing a compliant solution?
3. Which organization authored the SEI CERT C Coding Standard referenced in this lecture?
4. How might existing compiler implementations fail to protect against modifying const objects?
5. What is the risk assessment recommendation for this type of vulnerability?

📘 Lecture 41 — CASE STUDY – C++ APPLICATIONS SECURITY HARDENING

📖 Overview: This lecture presents a case study on C++ application security hardening based on Carnegie Mellon Software Engineering Institute guidelines. It focuses on key coding rules to prevent vulnerabilities, with a special emphasis on the critical rule CON50-CPP regarding mutex management in concurrent programming.

🗂️ Topics Covered

The lecture introduces ten rule categories for C++ security hardening from the SEI CERT C++ Coding Standard: Declarations and Initialization, Expressions, Integers, Containers, Characters and Strings, Memory Management, Input Output, Exceptions and Error Handling, Object Oriented Programming, and Concurrency. A detailed case study is provided for the concurrency rule CON50-CPP, including non-compliant code examples that illustrate race conditions when destroying mutexes.

📝 Lecture Summary

Rule 01. Declarations and Initialization (DCL)

[Summary not provided in source text — lecture section appears incomplete]

Rule 02. Expressions (EXP)

[Summary not provided in source text]

Rule 03. Integers (INT)

[Summary not provided in source text]

Rule 04. Containers (CTR)

[Summary not provided in source text]

Rule 05. Characters and Strings (STR)

[Summary not provided in source text]

Rule 06. Memory Management (MEM)

[Summary not provided in source text]

Rule 07. Input Output (FIO)

[Summary not provided in source text]

Rule 08. Exceptions and Error Handling (ERR)

[Summary not provided in source text]

Rule 09. Object Oriented Programming (OOP)

[Summary not provided in source text]

Rule 10. Concurrency (CON)

CON50-CPP. Do not destroy a mutex while it is locked

Mutex objects are synchronization primitives used to protect shared data from being concurrently accessed by multiple threads. Their fundamental purpose is to ensure that only one thread can access critical sections of code or shared data at any given time.

If a mutex object is destroyed while a thread is blocked waiting for the lock, or while a thread owns the lock, critical sections and shared data are no longer protected. This creates a serious security vulnerability where multiple threads could simultaneously modify shared data, leading to data corruption, race conditions, and undefined behavior.

The C++ Standard, [thread.mutex.class], paragraph 5 [ISO/IEC 14882-2014], states the following: "The behavior of a program is undefined if it destroys a mutex object owned by any thread or a thread terminates while owning a mutex object."

🔑 Definition — Mutex: A mutex (mutual exclusion object) is a synchronization primitive used to protect shared data from concurrent access by ensuring only one thread can acquire the lock at a time. 📐 Rule: Do not destroy a mutex while any thread owns it or is waiting for it → prevents undefined behavior and data corruption. 💡 Why this matters: Destroying a locked mutex violates the C++ Standard and can lead to race conditions, data corruption, and security vulnerabilities in multithreaded applications.

Non-Compliant Code Example:

This noncompliant code example creates several threads that each invoke the do_work() function, passing a unique number as an ID. Unfortunately, this code contains a race condition, allowing the mutex to be destroyed while it is still owned, because start_threads() may invoke the mutex's destructor before all of the threads have exited.

📌 Example:

• Context: A multithreaded C++ program creates multiple worker threads.
• Problem: The start_threads() function creates threads and then returns. The mutex destructor is called when the mutex goes out of scope, but if any thread still holds the lock, the mutex is destroyed while owned.
• Consequence: This race condition means the destructor runs before all threads have finished using the mutex, resulting in undefined behavior per the C++ Standard.
• Security Impact: Shared data protected by the mutex becomes vulnerable to concurrent access from multiple threads simultaneously.

⭐ Key Takeaways

The single most critical rule presented in this lecture is CON50-CPP: never destroy a mutex while it is locked or while any thread owns it, as this leads to undefined behavior and compromises the protection of shared data. The C++ Standard explicitly prohibits this practice. Programmers must ensure all threads have released their mutex locks before the mutex object's destructor is invoked. When creating multiple threads that share a mutex, proper synchronization must be implemented to prevent the mutex from being destroyed prematurely. The SEI CERT C++ Coding Standard provides ten categories of rules for hardening C++ applications against security vulnerabilities.

🧠 Quick Revision Questions

1. What is the fundamental purpose of a mutex object in multithreaded programming?
2. According to the C++ Standard, what happens if a mutex is destroyed while owned by any thread?
3. In the non-compliant code example, what specific race condition allows the mutex to be destroyed prematurely?
4. What are the complete ten rule categories listed in the SEI CERT C++ Coding Standard for C++ security hardening?
5. Why does destroying a mutex while a thread is blocked waiting for the lock represent a security vulnerability?

📘 Lecture 42 — CASE STUDY – JAVA APPLICATIONS SECURITY HARDENING

📖 Overview: This lecture examines security hardening of Java applications through a real-world case study from the Carnegie Mellon Software Engineering Institute. It demonstrates how to eliminate race conditions in multithreaded Java code using proper mutex locking patterns, which is critical for building secure concurrent applications.

🗂️ Topics Covered

The lecture covers a compliant code example that eliminates race conditions by extending the lifetime of a mutex, followed by a case study on Java applications security hardening from the SEI CERT Oracle Coding Standard for Java. It references the official SEI CERT coding standards wiki for secure Java programming practices.

📝 Lecture Summary

Compliant Code Example

The secure coding example demonstrates how to fix a race condition in Java by properly managing mutex locks. The key issue in the non-compliant code was that the mutex had a shorter lifetime than the shared resource it was protecting, allowing concurrent access when the mutex was destroyed or released prematurely. The compliant solution eliminates this vulnerability by extending the lifetime of the mutex to match or exceed the lifetime of the protected shared resource. This ensures the mutual exclusion guarantee holds for the entire duration when threads may access the critical section.

💡 Why this matters: Race conditions can lead to data corruption, inconsistent state, and security vulnerabilities that attackers can exploit to manipulate shared resources.

🔑 Definition — Race Condition: A race condition occurs when two or more threads access shared data concurrently, and the final result depends on the timing of thread execution, leading to unpredictable behavior.

📐 Formula for Secure Mutex Lifetime: Mutex lifetime >= Protected resource lifetime → The mutex must exist as long as any thread can access the shared resource it protects.

📌 Example:

• Problem: A BankAccount class has a balance field protected by a mutex lock. The non-compliant code creates the mutex inside a method, so the mutex is destroyed when the method returns. Two threads calling withdraw() simultaneously both acquire temporary locks, bypassing mutual exclusion.
• Compliant Solution: Make the mutex an instance field (class member) so it lives as long as the BankAccount object exists: private final Object lock = new Object();
• Result: Thread B must wait for Thread A to release the lock before accessing balance, eliminating the race condition.

Topic no 101: CASE STUDY – JAVA APPLICATIONS SECURITY HARDENING

The lecture references the Carnegie Mellon Software Engineering Institute (SEI) as the authority for secure Java coding standards. The specific resource is the SEI CERT Oracle Coding Standard for Java, available at: https://wiki.sei.cmu.edu/confluence/display/java/SEI+CERT+Oracle+Coding+Standard+for+Java

This is an official coding standard that provides rules and recommendations for developing secure Java applications. The case study uses the mutex lifetime principle as one specific hardening technique from this comprehensive standard. Other hardening areas covered in the standard include input validation, integer overflow prevention, secure serialization, and proper exception handling.

💡 Why this matters: Following established coding standards like SEI CERT is essential for building Java applications that resist common security threats such as race conditions, denial of service, and data corruption.

⭐ Key Takeaways

The most critical concept from this lecture is that a mutex's lifetime must be at least as long as the resource it protects to prevent race conditions. Developers must ensure locks are not created and destroyed within method scopes when protecting instance or class-level shared data. The SEI CERT Oracle Coding Standard for Java is the authoritative reference for secure Java coding practices, and students should consult this resource when implementing thread-safe code. The lecture demonstrates that extending mutex lifetime to the object level is a simple but effective hardening technique that prevents data corruption in multithreaded applications.

🧠 Quick Revision Questions

1. What is the primary security vulnerability that occurs when a mutex lifetime is shorter than the protected resource's lifetime?
2. How does extending the lifetime of a mutex fix a race condition in Java applications?
3. Which organization maintains the SEI CERT Oracle Coding Standard for Java?
4. In the compliant code example, where should the mutex object be declared (static/instance/local) to ensure proper lifetime?
5. What is the URL for the official SEI CERT Oracle Coding Standard for Java wiki?

📘 Lecture 43 — CS205 Information Security

📖 Overview: This lecture covers advanced security hardening topics including Java logging rules, Perl and Android/iOS case studies, Asterisk VoIP security, version control for IT assets, secure software images, and the vulnerability management lifecycle. It provides practical hardening methodologies for diverse IT environments and introduces key concepts like CVE, NVD, exploit databases, and the Qualys/Nessus scanning tools.

🗂️ Topics Covered

The lecture covers Java exception handling in logging (Rule 7), Perl format string vulnerabilities, CIS benchmarks for Android and iOS, Asterisk VoIP hardening steps, version control benefits and best practices, CIS control 5 for secure configurations, manual and automated hardening workflows, Qualys demo for compliance scanning, the security hardening lifecycle, hardening for non-standard assets, vulnerability management definitions and lifecycle (6 steps), reasons for insecure software, patch management importance, CVE/NVD/CVSS standards, exploit types and databases, effective VM program stages, security breach case studies (Home Depot, Anthem), best practices for patching, roles of Infosec and IT Ops teams, Nessus and Qualys features, VM scanner operation methodology, OpenVAS open-source scanner, scanning frequency recommendations, VM challenges and pitfalls, IT asset management challenges, UEM tools, software restriction policies, security engineering as the third layer of the security transformation model, DMZ architecture, firewall access lists, CIS 20 Critical Security Controls (CSC 1-5, 9, 10), ISO 31000 risk management process, incident management top 10 considerations, and ITIL change management types.

📝 Lecture Summary

Rule 7 – Prevent exceptions while logging data

Exceptions thrown during logging can prevent successful logging and allow attackers to conceal critical security exceptions. Programs must ensure data logging continues correctly even when exceptions occur during the logging process.

🔑 Definition — ERR02-J: Prevent exceptions while logging data to maintain security logging integrity.

The non-compliant code example writes a critical security exception to the standard error stream, which is inadequate because the stream may be exhausted or closed, the trust level may be insufficient for sensitive exceptions, an I/O error would cause the exception to be lost, and an attacker can disguise the exception among innocuous ones.

📐 Solution: Use java.util.logging.Logger (the default JDK 1.4+ logging API) or other compliant mechanisms like log4j. Typically only one logger is required for the entire program.

CASE STUDY – PERL APPLICATIONS SECURITY HARDENING

Rule 1 — IDS30-PL: Exclude user input from format strings Never call any formatted I/O function with a format string containing user input. An attacker who controls the format string can crash the Perl interpreter, cause denial of service, modify values using the %n conversion specifier, and divert control flow. printf() and sprintf() should never be passed unsanitized format strings.

📌 Example: A non-compliant Perl authentication script uses printf() with user-supplied password as the format string. The compliant solution avoids printf() and uses print() instead, which provides sufficient functionality.

Case Study: Security Hardening – Android (CIS Benchmarks, Google Android 7)

1.15 Ensure Android Device Manager is set to Enabled (Not Scored)

• Profile applicability: Level 2
• Rationale: If you lose your Android device, you can use Android Device Manager to find, ring, lock, or erase device data remotely.
• Audit Steps: System Settings → Personal → Security → Device administration → Device administrators → Verify Android Device Manager is enabled.
• Remediation Steps: Same path → Tap Android Device Manager → Activate this device administrator.
• Impact: Google may track your device location anytime.
• Default Value: Android Device Manager is not enabled by default.

Case Study: Security Hardening – Apple iOS 10 (CIS Benchmarks)

3.2.1.12 (L2) Ensure 'Allow modifying cellular data app settings' is set to 'Disabled' (Not Scored)

• Profile applicability: Level 2 - Institutionally Owned Devices
• Rationale: Forcing cellular data to remain active supports remote locating and erasure capability.
• Audit: Via Apple Configurator → Restrictions tab → Functionality → verify checkbox for "Allow modifying cellular data app settings" is unchecked. Or on device: Settings → General → Profile → Restrictions → confirm "Changing app cellular data usage not allowed" is displayed.
• Remediation: Uncheck the checkbox in Apple Configurator and deploy the configuration profile.
• CIS Controls: 5.1 Minimize And Sparingly Use Administrative Privileges.

CASE STUDY – ASTERISK VOIP SECURITY HARDENING (Part 1)

1. Physically secure your IP PBX and network hardware.
2. Never use default passwords on any system. Use strong passwords.
3. Never use the same username and password on your extensions (e.g., password 101 for extension 101 is a serious risk).
4. Place your PBX behind a Firewall. Use VPNs for remote access, limit to specific IP addresses, allow only necessary ports, disable anonymous WAN requests (ICMP/PING).
5. Use "permit=" and "deny=" lines in sip.conf to only allow a small range of IP addresses access to extensions.
6. Keep inbound and outbound routing separate (different contexts) to prevent toll fraud if an intruder gains access.

CASE STUDY – ASTERISK VOIP SECURITY HARDENING (Part 2)

7. Limit registration by extensions to your local subnet using ACL (permit/deny) in SIP.conf to fend off brute force registration attempts.
8. Disable channels and services not in use (e.g., skinny, MGCP). For Asterisk PBXs, unload modules in /etc/modules.conf.
9. Set "alwaysauthreject=yes" to prevent Asterisk from telling SIP scanners which extensions are valid. Also install a SIP port firewall to block scanning of ports 5060/5061.
10. Limit and restrict routing and phone number dial plans — restrict high-cost destinations and premium numbers (e.g., 0900).
11. Audit your system security regularly.

Version Control For IT Assets

Benefits of version control:

1. Organized, coordinated management of changes by one or many individuals (possibly geographically dispersed).
2. Coordinated management for emergency hot-fixes, routine maintenance, upgrades, and new features with overlapping development timeframes.
3. An auditable change history (what changed, when, and by whom).
4. A reliable master copy of current production assets.
5. A reliable master copy to build/configure the production environment.
6. Reliable copies of previous production versions.
7. Ability to see specific differences between distinct versions of a given asset.

Security controls: Access control measures, privileged management, backups.

Version Control Best Practices

1. Choose a source control system.
2. Keep source code in source control (not generated/compiled files).
3. Ensure working file is from the latest version.
4. Only check-out the file being worked upon.
5. Check in immediately after alterations.
6. Review every change before committing — utilize the diff function.
7. Commit often — every commit provides a rollback position.
8. Make extensive detailed notes in check-in comments about why changes were made.
9. Developers must commit their own changes (only).
10. Use the ignore button for files that should not be committed; add pre-commit filters.
11. Ensure external dependencies are added to source control.

SECURITY HARDENING - SECURE SOFTWARE IMAGES (CIS 20 Critical Security Controls, Control 5, Version 7)

5.1 Establish Secure Configurations: Maintain documented, standard security configuration standards for all authorized operating systems and software. 5.2 Maintain Secure Images: Maintain secure images or templates for all systems based on approved configuration standards. Compromised systems should be re-imaged using these templates. 5.3 Securely Store Master Images: Store master images on securely configured servers, validated with integrity monitoring tools. 5.4 Deploy System Configuration Management Tools: Automatically enforce and redeploy configuration settings at regularly scheduled intervals. 5.5 Implement Automated Configuration Monitoring Systems: Use a Security Content Automation Protocol (SCAP) compliant monitoring system to verify configurations, catalog approved exceptions, and alert on unauthorized changes.

SECURITY HARDENING – MANUAL & AUTOMATED WORK

Step 1: Scan an IT asset using Qualys compliance scan, NESSUS compliance scan, or CIS CAT PRO Tool – acquire report of failed controls. Step 2: Apply the failed controls using AD (for Windows) or manually for other systems. Step 3: Use the automated feature to verify controls are in place – compare 'before' and 'after' report. Step 4: Manually verify any discrepancies. Step 5: For assets that cannot be scanned, conduct manual validation using sampling (e.g., 15-20% of assets checked at random, or 15-20% of controls checked on an asset).

QUALYS DEMO – SECURITY HARDENING (Topics 111-112)

Qualys is an excellent tool for compliance scanning. The demo covers:

• Qualys website free trial
• QualysGuard home screen
• Policy Compliance home screen (5 steps)
• Help options, online help, resources, training videos (Vimeo)
• Adding IP addresses to scan
• Configuring scan settings
• Creating a new compliance profile (e.g., 'CIS Scan Test Profile')
• Configuring authentication
• Compliance library: CIS Red Hat Enterprise Linux 7
• Policy editor
• Launching compliance scans from the main Qualys dashboard

SECURITY HARDENING – LIFECYCLE

1. Harden IT Asset: Pursue the 8-step hardening methodology.
2. Periodic Validation: Check periodically (every quarter) for changes to the established standard/baseline.
3. Seek Updated Hardening Benchmarks: Subscribe to feeds from CIS, DISA, NIST NCP (National Checklist Program) repository.
4. Implement Additional Controls: Update controls by studying changes.
5. Pursue & Implement Controls That May Require Additional Working: Some controls may have caused crashes/malfunctions or were not possible due to dependencies. Enhance the % of implemented controls.

Hardening When CIS/DISA STIG Not Available

For IT assets like software applications (ASP.NET, PHP, other), or applications such as Asterisk deployments that do not have a CIS/DISA STIG:

• Step 2: Research: Look up Google, case studies, and whitepapers.
• Other considerations: Implement on test setup, test controls, use security testing tools, perform third-party penetration testing, follow vendor best-practices for application security hardening.
• With effort and by following the 8-step methodology, all types of assets can be hardened.

QUALYS POLICY LIBRARIES (Topic 115)

Qualys has built-in libraries for creating scanning policies: CIS, QUALYS, MANDATE, DISA, VENDOR. Libraries include policies like DISA STIG, Qualys SAP Adaptive Server Enterprise 16, and various vendor policies. Qualys has a vast number of options for Compliance Scans that should be fully explored through the trial.

Security Hardening For Outsourced IT Assets

IT Outsourcing examples: Call centers, hosted servers, software development, workstation helpdesk, network services. Mechanism: Information Security Policy, vendor contract (with right-to-audit clause), security project with project manager, periodic reviews, penalties for non-compliance. Important considerations: Enter security requirements into RFP, include in vendor evaluation, proceed with contract including InfoSec clauses, conduct awareness training. Security evaluations: Include outsourced scope in periodic internal audit, ask for third-party security review, vulnerability assessment and penetration test (if applicable), spot security checks.

What is Vulnerability Management?

🔑 Definition — Vulnerability: A cyber-security term referring to a flaw in a system that can leave it open to attack. It may refer to any type of weakness in a computer system, procedures, or anything that leaves information security exposed to a threat.

🔑 Definition — Vulnerability Management: The "cyclical practice of identifying, classifying, remediating, and mitigating vulnerabilities".

🔑 Definition — Vulnerability Assessment (VA): A process that defines, identifies, and classifies the security holes (vulnerabilities) in a computer, network, or communications infrastructure.

Common vulnerability scanners: OpenVAS, Nessus, Qualys, Rapid7.

How to fix vulnerabilities: Keep software security patches up to date. These patches remedy flaws or security holes found in the initial release. Stay informed about current vulnerabilities.

What Are The Steps In VM Lifecycle? (6 Steps)

1. Analyze assets: Examine assets to scan, gather details on IP subnet, look at potential network traffic issues, inform asset owners and department heads.
2. Prepare scanner: Set parameters, select scan type, look at credentials-based scan, explore/research plug-ins, do a test run, coordinate with asset owner.
3. Run vulnerability scanner: Run the automated scan, monitor network performance degradation, generate report.
4. Assess results: Evaluate results, prioritize according to risk level, collate results for asset owners, communicate results and remediation timelines.
5. Patch systems: Research vulnerabilities, evaluate fixes and remediation methods, test patches/fixes, apply patches, monitor results.
6. Verify (re-scan): Re-scan to confirm the scanner gives a positive report, collate results, report findings.

Why Is Software Insecure?

Software is being developed with many defects exploitable by attackers due to the race to meet deadlines with little emphasis on security.

Gary McGraw's "trinity of trouble" for software security:

• Connectivity: Ever-increasing computer connectivity and internet access enhances exposure to attacks.
• Extensibility: Systems that support updates/plug-ins make it difficult to keep the constantly-adapting system free of vulnerabilities.
• Complexity: Software systems grow exponentially in size and complexity, making vulnerabilities unavoidable.

Carnegie Mellon University's CyLab estimates commercial software contains 20 to 30 bugs per 1,000 lines of code. Windows XP contains at least 40 million lines of code — that's potentially 1 million bugs.

Monoculture (Dan Greer): The security situation deteriorates when nearly all end-user computers rely on a single operating system subject to the same vulnerabilities worldwide.

Why Is A VM Program Required?

🔑 Definition — Patch: A piece of software designed to update a computer program or its supporting data to fix or improve it, including fixing security vulnerabilities and other bugs.

🔑 Definition — Patch Management: An area of systems management that involves acquiring, testing, and installing multiple patches to an administered computer system.

Patch management tasks: Maintaining current knowledge of available patches, deciding appropriate patches, ensuring proper installation, testing after installation, documenting procedures.

Risk of not patching: Leaving the door open for malware attacks. The timeframe between an exploit and when a patch is released is getting shorter. Defects in clients (web browsers, email programs, image viewers, IM software, media players) may allow malicious websites to compromise your computer with no action other than viewing.

A VM program addresses timely management of patching to ensure vulnerabilities are not present for hackers to exploit.

What Is CVE & Vulnerability Database?

🔑 Definition — CVE (Common Vulnerabilities and Exposures): A list of information security vulnerabilities and exposures that aims to provide common names for publicly known cyber security issues. The goal is to make it easier to share data across separate vulnerability capabilities (tools, repositories, and services) with this "common enumeration."

🔑 Definition — NVD (National Vulnerability Database): The CVE dictionary augmented with additional analysis, a database, and a fine-grained search engine. The NVD is a superset of CVE and is synchronized with CVE so updates appear immediately.

🔑 Definition — CVSS (Common Vulnerability Scoring System): An open standard for assigning vulnerability impacts used by a variety of organizations. The NVD uses CVSS Version 2 and NISTIR 7946 describes methodologies for using CVSS.

All major vendors publish their security vulnerabilities online (Microsoft, Oracle, Cisco, etc.).

What Is An Exploit?

🔑 Definition — Exploit: A program or code that takes advantage of a security hole (vulnerability) in an application or system so an attacker can use it for their benefit.

• Remote exploit: Works over a network and exploits the vulnerability without any prior access to the vulnerable system.
• Local exploit: Requires prior access and usually increases the privileges of the person running it past those granted by the system administrator.

Exploit Database: A CVE compliant archive of public exploits and corresponding vulnerable software for penetration testers and vulnerability researchers. It is a repository for exploits and proof-of-concepts rather than advisories.

🔑 Definition — Zero-day exploit: A zero-day vulnerability refers to a hole in software unknown to the vendor. This security hole is exploited by hackers before the vendor becomes aware and fixes it — this exploit is called a zero-day attack.

Effective Vulnerability Management: Stage 2

Stage 1: Security hardening — Taking stock of assets, prioritizing, establishing an MSB, implementing controls with CIS/DISA/Other benchmarks, basic/broader security hardening.

• Stage 1 (Hardening) is equivalent to tightening all the screws on machinery — reduces impact of an attack (like a shield).
• Stage 2 (Patching) will seal all entry points for an attacker to gain access.
• Both stages are equally important and necessary.

Security Breach Case Study 1: Home Depot 2014

• 56 million payment cards compromised in early September 2014.
• Sequence of events: Attackers gained access via a third-party vendor's logon credentials → exploited a zero-day vulnerability in Windows to pivot to the corporate environment → installed memory scraping malware on 7,500+ self-checkout POS terminals → grabbed 56 million credit/debit cards and 53 million email addresses.
• Failures: No secure configuration of POS terminal software/hardware, no regularly scheduled vulnerability scanning, no proper network segregation between corporate and POS networks, missing vendor management of IDs/access management, and missing network monitoring.

Security Breach Case Study 2: Anthem (Health Insurer)

• Affected 78.8 million individuals.
• Sequence of events: User opened a phishing email (Feb 18, 2014) → malicious files downloaded → hackers gained remote access to the computer and 90+ systems → moved laterally and escalated privileges → compromised 50+ accounts and 90 systems → accessed the enterprise data warehouse → exfiltrated 78.8 million unique user records.
• Vulnerabilities: Exploitable vulnerabilities found in the network; lack of user security awareness training to prevent phishing.
• Remediation: Implemented two-factor authentication on all remote access tools, deployed privileged account management, enhanced logging, completed a full password reset for privileged users, suspended remote access pending 2FA, created new Network Admin IDs.

Best Practices For Applying Security Patches

Guiding principle: "The risk of implementing the service pack, hotfix and security patch should ALWAYS be LESS than the risk of not implementing it."

1. Use a change control process with an identified owner, customer input path, audit trail, clear announcement/review period, testing procedures, and a well-understood back-out plan.
2. Read all related documentation and peer review — ensure the update is relevant, won't cause other issues, check dependencies and sequencing instructions.
3. Apply updates on a need-only basis.
4. Testing.
5. Plan to uninstall.
6. Working backup and production downtime.
7. Always have a roll-back plan.
8. Don't get more than 2 service packs behind.

Who Conducts Vulnerability Management?

Role of Infosec team:

• Takes primary ownership of the VM process
• Runs scanning after coordinating with IT Ops
• Shares scanning reports with IT teams and management
• Tracks remediation timelines
• Understands criticality and helps prioritize
• Studies security patch details as backup
• Assists with change management

Role of IT Ops team:

• Owner of the IT asset
• Receives and studies the vulnerability scan report
• Understands criticality, impact, and dependencies
• Helps develop project plan and timelines
• Tests patches in test environment
• Takes backups, develops roll-back plan
• Takes downtime and owns change management
• Implements patches
• Monitors systems after implementation
• Rolls back if necessary
• Creates documentation

Nessus Features

• Reports: Customize by vulnerability or host, create executive summary, compare scan results, targeted email notifications.
• Scan Types: Asset discovery, un-credentialed vulnerability discovery, credentialed scanning for system hardening and missing patches.
• Compliance & Config Scans: Compliance auditing (FFIEC, FISMA, GLBA, HIPAA, PCI, SOX, etc.), configuration auditing (CERT, CIS, DISA STIGs, ISO, NIST, NSA).
• Risk scores: Vulnerability ranking based on CVE, five severity levels (Critical, High, Medium, Low, Info), customizable severity levels.
• Nessus is a cost-effective scanner with CIS and DISA compliance templates. Has some flaws and bugs but is overall useful.

Qualys Features

• Cloud-based service with on-premise device options
• Complete suite, scalable and immediate deployment
• Asset discovery, prioritize & manage remediation tickets
• Continuous monitoring service
• Policy compliance scanning
• Qualys Secure Seal for websites
• Website scanning, compliance scanning
• Annual subscription service model
• Convenient and scalable with several modules; subscription-based pricing can be expensive; advantages due to cloud-based service.

How Do VM Scanners Work? (Qualys Methodology)

The scanner follows steps an attacker might take:

1. Check if remote host is alive — probe well-known TCP/UDP ports. If at least one reply is received, continue.
2. Firewall detection — check if host is behind any filtering device to gather network infrastructure info.
3. TCP/UDP Port scanning — detect all open ports (default: ~1900 TCP ports and 180 UDP ports).
4. OS Detection — send specific TCP packets to open and closed ports.
5. TCP/UDP Service Discovery — identify which service runs on each open port.
6. Vulnerability assessment based on services detected — check service version to detect only applicable vulnerabilities. Every detection is non-intrusive (never exploits vulnerability if it could negatively affect the host).

Limitations: Scanners work like antivirus programs using databases of vulnerability descriptions; there may be false positives or false negatives.

Open Source Vulnerability Scanners (OpenVAS)

• Simple, free (open source) VA scanner
• Approximately 50k Network Vulnerability Tests
• Has source code documentation, virtual images for download, and mailing lists on website
• Login/password: livedemo (at openvas.org/livedemo.html)

Suggested Frequency For VM Scanning

• Pre-requisites: Information security team, vulnerability management policy, in-house scanner or OpenVAS tool, trained staff.
• At the start: Scanning once a year or not at all — vulnerabilities not remediated, lack of discipline/management support.
• As organizations mature (Quarterly): Quarterly scan, quarterly remediation, quarterly report to IT Steering Committee.
• Mature organizations: Monthly scan, monthly remediation, quarterly or bi-annual external VA/PT, monthly reports.
• Most mature organizations: Fortnightly scan, fortnightly remediation, monthly reporting.

VM Challenges & Pitfalls

1. Internal expertise on VM tool: Not too much expertise required — create testbed, monitor traffic pattern, train staff, patch small portions first.
2. Not enough support from IT teams: Create reports, share among IT management, highlight/educate risks to management and board, create departmental competition and relationship-building.
3. Patching causing application failure: In test environment create workarounds or compensating controls, test them, document them.
4. Not enough management support: Share reports highlighting recent incidents, share industry-specific/geographically relevant breach reports, create awareness.

IT Asset Management Challenges

The typical enterprise has hundreds or thousands of IT assets with fast-paced business changes. Challenges:

• Asset discovery & tracking: New assets added & old removed, temporary/replacement machines, travelling staff, test beds, vendor environments.
• Antivirus status: Working and updated AV critical; geographically dispersed networks; some stations not responding/updating.
• Windows & OS updates: Windows, Linux, Unix, AIX, database systems; vendor patches from multiple sources; testing patches; acquiring downtime windows; monitoring performance.
• Patch management: Scanning for vulnerabilities, passing reports to IT teams, tracking remediation, re-scanning, reporting to management.
• Change management: Inherent to all change processes; requires reviews and approvals; Configuration Management Database (CMDB) or repository.

ASSET MANAGEMENT TOOLS FOR SECURITY FUNCTIONS (Topic 144)

Asset management helps with: 1. Patch management, 2. Software whitelisting, 3. Software assets discovery/management, 4. Enterprise tracking and reporting.

Gartner — Unified Endpoint Management (UEM): Tools that combine management of multiple endpoint types in a single console. UEM functions (Gartner UEM 2018):

1. Configure, manage, and monitor iOS, Android, Windows 10, macOS, and some IoT/wearable endpoints.
2. Unify application of configurations, management profiles, device compliance, and data protection.
3. Provide a single view of multi-device users, enhancing end-user support and gathering detailed workplace analytics.
4. Act as a coordination point to orchestrate activities of related endpoint technologies (identity services, security infrastructure).

Microsoft Software Restriction Policies (SRP) for Whitelisting: A Group Policy-based feature that identifies software programs and controls their ability to run. Can create highly restricted configurations allowing only specifically identified applications to run. Integrated with Microsoft Active Directory and Group Policy.

WHAT IS SECURITY ENGINEERING? (Layer 3 of Security Transformation Model)

Consists of more in-depth and complicated security activities taking more time and effort, often related to security architecture. Types of activities:

• Firewall granular access lists
• Building an effective DMZ architecture
• Segregating the network with VLANs
• Adding security tools like SIEM, FW, DLP, NAC
• App-DB encryption

DMZ Architecture Case Study: DMZ is an important zone for devices that need to communicate with the outside world (web servers, email gateways, web gateways).

FW Access List Case Study: Most of the industry has not built granular access lists. Most FWs have "allow all" for traffic. Granular access lists need to be built based on servers or traffic flows.

Why at Layer 3?: Low hanging fruit first. Teams tend to get bogged down with advanced security tasks that take time, effort, and budget approval.

WHAT IS THE OBJECTIVE OF SECURITY ENGINEERING?

• Security architecture as per best-practices
• The right security devices in the right places
• Effective security configuration of security devices (features)
• Optimum operation of security devices
• Aggregate controls

Examples: FW first and then IPS; Edge FW, data center FW; Malware protection at network edge; VPN termination on remote access VPN device; VPN tunnels for extranet