NZ Incident Response Bulletin - December 2021
The December edition of the NZ Incident Response Bulletin was published today. The bulletin is a monthly high-level executive summary containing some of the most important news articles that have been published on Forensic and Cyber Security matters during the last month. Each Bulletin also includes a section of our own content, based on a trending theme, this months being?“Cyber Controls # 16 to 18”.
Each article contains a brief summary and where appropriate, a linked reference on the web for detailed information.
We'll give you a brief summary of each article, and a link to more information. Why do we publish this bulletin? Because we want to keep you up to date with the latest Forensic and Cyber Security news, so that you aren't caught by surprise - and you'll know about risks and changes before they become problems.
CIS Control 16: Application Software Security
Manage the security life cycle of in-house developed, hosted, or acquired software to prevent, detect, and remediate security weaknesses before they can impact the enterprise.
Why is it needed?
Access management applications enable users to easily manage a business’s sensitive data and to grant access to system resources. Attackers with access to these applications can therefore also directly use these them to compromise data without needing an elaborate hacking sequence to bypass network security controls. Hence the need to strongly protect user credentials, as outlined in CIS control 6. However, even without access to user credentials, cyber criminals will target applications by looking for application vulnerabilities. Attackers will then exploit these vulnerabilities to take control of network assets.
Application vulnerabilities may exist due to insecure design, coding mistakes, poor authentication practices, infrastructure weaknesses or insufficient testing. Today’s applications are more complex and dynamic. Agile “DevOps” cycles are now used that involve frequent code change and most applications are no longer built from scratch but assembled from many contributing parts. All these factors have increased the complexity and challenge of building secure applications. Additionally, the increased use of Software as a Service (SaaS) has decreased the visibility of some application development and security practices and consequently the level of risk they carry. Business should therefore follow the safeguards outlined in this control for all application development and any extension or customisation of SaaS products.
How is it implemented?
No part of this control is recommended as part of basic security hygiene or IG1 (small to medium-sized businesses with limited IT and cybersecurity expertise) however there are 14 safeguards to consider for more mature organisations. To start implementing this control, a secure application development process must be established. Ideally this will introduce security needs early in any software development lifecycle and include addressing secure design and coding standards, developer training, vulnerability management, secure testing processes and third-party code security. The vulnerability process would provide a mechanism for third parties to report vulnerabilities and include procedures for intake, assignment, remediation and testing of vulnerabilities. Additionally, a tracking system should be implemented that can report key metrics on the application vulnerability process, as well as performing root cause analysis on identified vulnerabilities.
Procedures for managing third party components is also required to satisfy this control. An inventory of third-party software components should be created, sometimes called a “bill of materials.” This inventory should include any risks that each component could pose. Only up-to-date and trusted third-party software components must be allowed. Further safeguards for this control include:
The safeguards outlined above satisfy IG2 requirements. Larger and more mature teams should consider the additional safeguards of:
Application software security is a large and detailed area and therefore the safeguards in CIS control 16 outline the most critical areas only. The NIST published the Secure Software Development Framework (SSDF) in 2020 to help organisations build their application security requirements and understand whether a products development follows best practice. Using this resource to extend your organisations knowledge is highly recommended. Further recommended industry resources are also freely available as references including: SAFECODE Application Security Addendum, The Software Alliance Framework and OWASP guidelines.
CIS Control 17: Incident Response Management
Establish a program to develop and maintain an incident response capability (e.g., policies, plans, procedures, defined roles, training, and communications) to prepare, detect, and quickly respond to an attack.
Why is it needed?
The intent of incident response management is to identify threats to the organisation, respond to them before they can spread, and remediate them before they cause harm. A well-rounded cybersecurity programme follows a recognised framework and includes capability in each area of identification, protection, detection, response, and recovery. Often response and recovery are overlooked in less mature organisations. As protections cannot be relied upon 100%, the ability to respond to a cyber incident and recover from this effectively is therefore vital.
An attacker can dwell within systems for days, weeks, and months, before being detected. This gives them ample time to find and review confidential data and traverse laterally within an organisations network, potentially planting further vulnerabilities and “backdoors” for later compromise. Due to the recent rise in ransomware this behaviour has become more common. A common response to cyber incidents in immature organisations is to just “re-image” assets to the original state and move on. However, without using a thorough incident response process to fully understand the scope of any incident, how it happened, and how it can be prevented in future, the risk of the same or a similar threat will remain.
Smart business decisions are essential to reduce any further potential impact of the cyber incident particularly when communicating with stakeholders, meeting legal and regulatory obligations, and prioritising remediation activities. If an organisation does not have a cyber incident response plan in place they will struggle with these decisions when a cyber incident occurs. Even with great people, under the pressure and time constraints of a cyber incident it is extremely difficult to know the correct investigative procedure to follow and what reporting, data collection, legal protocols and communication strategies should be undertaken to minimise harm.
领英推荐
How is it implemented?
This control includes safeguards that constitute minimum basic security hygiene for all businesses. Even small organisations with limited resources to conduct incident response activities should have an incident response plan. The plan at a minimum should identify the source of protections and detections (e.g.: where an alert or notification of a potential cyber incident may come from), a list of who to call upon for assistance, and communication plans and mechanisms to inform required parties such as leadership, employees, regulators, partners, and customers.
At a basic level:
After these basic safeguards are implemented, it is recommended a full incident response process be established. Key roles and responsibilities for incident response activities across the business should be defined and reviewed periodically. Primary and secondary communication mechanisms to be used during an incident must also be defined. It is important to remember that some standard communication channels such as email may be either unavailable or no longer secure for use during a cyber incident.
Once these procedures are in place then they must be tested. The incident response team or a third-party should conduct regular scenario walk through’s (sometimes referred to as tabletop simulations or gold-teaming exercises) to fine-tune the business response. Walk throughs allow the business to fully understand their roles and responsibilities in a cyber incident and these scenarios can effectively identify gaps or dependencies in the current procedures. Finally conducting post incident reviews allows lessons learned to be incorporated into plans and help prevent incident recurrence.
Finally, more mature organisations can also consider including threat intelligence and threat hunting into their incident response process. This enables proactive monitoring for tactics, techniques, and procedures (TTPs) of likely threat actors and can help focus and define the response procedures most suitable for the organisation.
CIS Control 18: Penetration Testing
Test the effectiveness and resiliency of enterprise assets through identifying and exploiting weaknesses in controls (people, processes, and technology), and simulating the objectives and actions of an attacker.
Why is it needed?
Penetration testing goes a step further than basic security hygiene and therefore it is not included at IG1 level. However, this control includes safeguards at both IG2 and IG3 for consideration.
An organisations cyber defence posture can be strong, but due to the everchanging and complex nature of technology and the evolving nature of cyber-attacks, it is rarely perfect. Penetration testing allows a business to test their defensive controls and identify gaps in these that will impact overall resiliency. Penetration testing can be focused on external network attacks, internal network threats, applications, systems, or devices and may include social engineering techniques to trick users or physical security breaches. It differs from vulnerability testing (described in CIS control 7) as it is an active attempt to exploit weaknesses to see how far an attacker may get, and what data, systems, and business processes may be impacted by success.
Penetration tests can be used as a compelling demonstration of organisations weaknesses, to validate whether the business has the correct defences in place, or as a tool to verify the correct operation of currently deployed defences. They often involve significant human involvement and analysis in conjunction with custom scripts and tools. As penetration testing can be is complex, it may also be expensive and introduce risk, such as the unexpected shutdown of a system or the possibility of data deletion or corruption. Because of this it should only be undertaken by experienced specialists from reputable vendors.
How is it implemented?
The first step to satisfying this control is to establish and maintain a penetration testing program. This includes determining the scope of any penetration testing engagement (For example, will the testing include network, web application, API’s, hosted services, physical controls) and key factors such as acceptable hours for testing, excluded attack types, and confidentiality of findings. Defining scope is critical to establish clear rules of engagement and minimise any possible unexpected collateral damage that can occur from invasive testing.
Periodic external penetration tests (based on the requirements outlined in the program established above) should be undertaken at least annually. An external test should include reconnaissance to detect exploitable data. The number of internal people that know about the test should be minimised and ideally a business would focus on testing assets that hold the highest value information or production processing functionality. Consider conducting a penetration test through third-party legal counsel to ensure the report is protected from disclosure. After a test is conducted any test findings must be remediated.
Advanced safeguards in this control include validating security measures after each penetration test and performing periodic internal penetration test. Further detail and support for Penetration testing can also be found in the following resources:
This brings us to the end of our deep dive on the CIS control set. Using this control set gives your organisation a structured and prioritised plan for improving your cyber security posture. We highly recommend starting to define your cyber security program by measuring your organisation against the IG1 group of CIS controls which make up the basic security hygiene measures for any business.
The Bulletin:
To obtain a full copy of the Bulletin, please visit?https://incidentresponse.co.nz/bulletin
Bimlesh Reddy (MSOC ,MCSE,Dip EE)
Forensic Computing Expert Witness and Cyber Security Consultant
2 年This month brings us to the end of our CIS control deep dive by looking at the final three controls: 16, 17 and 18. CIS controls 16 and 18 are more advanced options for business who are medium to large and employ individuals responsible for managing and protecting IT infrastructure. However, CIS 17 is highly recommended for all businesses for basic security hygiene.