activities, for example: § Processes whose loss or degradation make it impossible to carry out the mission of the organization § Processes that contain secret processes or processes involving proprietary technology § Processes that, if modified, can greatly affect the accomplishment of the organization's mission § Processes that are necessary for the organization to comply with contractual, legal or regulatory requirements Source: ISO/IEC 27005:2011 B.1 Why does it matter?
the exercise of the organization's mission or business § Personal information, as can be defined specifically in the sense of the national laws regarding privacy § Strategic information required for achieving objectives determined by the strategic orientations § High-cost information whose gathering, storage, processing and transmission require a long time and/or involve a high acquisition cost Source: ISO/IEC 27005:2011 B.1 Why does it matter?
of an asset § Ex: Used to gain access to a system § Controls § Software patches § Configuration changes § Flawed software or service removal § Threats: Exploit vulnerabilities and cause damage to the asset § Ex: exploit scripts, worms, viruses, rootkits e Trojan horses Why does it matter?
Test Predictable, because network adm is aware of the tools being used May include several false postitives Produces a report with recommendations for risk reduction Penetration Test Exploits specific attack vectors (services or assets) May happen unannounced, to test incident response Trustworthy because provides evidence of break in (root!) Pen Testing = Proof of Concept against vulnerabilities Produces a binary result: got root or not
the Organization is aware of a serious security flaw. If there is awareness and no patching, there is no due diligence § If a security incident is related to a known vulnerability not patched by the Organization, it may open a possibility to claims of damage Vulnerability analysis without patching has little value Little analysis and lots of patching is better than lots of analysis and little patching
should contain instructions on removing vulnerabilities by installing patches or performing workarounds, as well as the actual patches when applicable § Linking resources § While the creation of a database is recommended, resource constraints may limit an organization to listing only Web sites or specific Uniform Resource Locators (URL) for each patch
Patches should have their authenticity verified, using PGP or digital certificates § Antivirus software should scan all patches before installation § And before that, make sure the antivirus and its signature database are updated § Patches e configuration changes should be tested in the testing environment, they can bring unexpected results § Some patches are extremely complicated and largely affect the operating system by replacing files and changing system settings
• To cancel the operation avoids the risk but may not be the best option. • The objective is to make money with adequate risks. Transfer Risk • Insurance won’t transfer risk. It will only transfer risk of financial losses. • Health insurance won’t transfer death risk. Life insurance? Not a chance. • Control cost is the cost of insurance. Accept Risk • May not be so bad. Depends on factors and costs. • A soccer coach knows there is about 50/50 chance of winning the match, even managing the stronger team. • Risk is inherent to business.
of the threat or vulnerability and which systems are vulnerable or exposed, focusing on critical systems § Determinate the risk of applying the patch and if the patch affects the functionality of other applications and services (should also be addressed in Changes Management)
it is better to make sure there is a recent backup copy. This way, it is easier to restore the environment § Many assets § Patch implementation gets very hard when there are thousands of assets. Automated solutions (EPM – Enterprise Patch Management) may be the answer.
considered § Threat level § Internet accessible assets, many systems to be patched § Exploitation risk § If the vulnerability may be easily exploited, the patch (or virtual patch) should be immediately installed § Exploitation consequences § Critical systems or systems containing sensitive information should be patched as soon as possible
reduce performance or make the systems uninstable § Patches may be incompatible with other softwares § User may lose informatgion when the agents reboots the system to install the patch § EPM agent may be itself another security threat § Mobile users may have problem when EPM tries to install a large amount of patches as the user logs on
the result of poorly formed system configuration or user administration policies, and inadequate provisioning or change management processes. § Eliminating root causes requires improvements in the policies and processes that are used to provision, configure and change systems, and administer users.
patch and vulnerability management program and apply corrective actions as necessary. § Without such a capability, even the best-designed security architectures can be susceptible to penetration or other forms of exploit. Establishing metrics Metric Name (Example) Units Vulnerability ratio Vulnerabilities/Host Unapplied patches ratio Patches/Host Network services ratio Services/Host Response time for vulnerability and patch identification Time Patch response time (critical) Time
for which a widespread worm will be created, manual monitoring and patching is much more cost-effective than responding to a worm infection § Enterprise Patch Management (EPM) § Given that patches are constantly released, manual patching becomes prohibitively expensive unless the operating environment consists of only a few software packages (thus decreasing the total number of patches needed) Planning ahead
should be using EPM § Even small organizations should be migrating to some form of automated patching tool § Manual patching is becoming ineffective as the number of patches grows and as attackers develop exploit code more rapidly § Only uniquely configured computers and appliance- based devices should continue to be patched manually Planning ahead
primary categories of enterprise patch management tools § those that use agents § those that do not § Some products support both approaches and allow the administrator to choose the approach that is most efficient for the environment
features, and services can mean more bugs, vulnerabilities, and patches § Delay implementing recently released major operating systems or applications until the experiences of others can be included in the decision-making process § Consider software validated by independent testing. For the greatest assurance, the software’s source code should be evaluated § Use only versions of software that are currently supported. Obsolete software beyond its lifecycle often has flaws that are only addressed in the newer, supported versions Planning ahead
following items § Hardware type and model § Operating system version and patch level § Major installed applications (version and patch level) § Security settings for the operating system and applications. § In many cases, these standardized configurations can be maintained centrally, and changes can be propagated to all participating IT resources. Planning ahead
is significantly more complicated than merely applying the appropriate patch § The vulnerability that was exploited must be patched § It will not eliminate rootkits, backdoors, or most other changes that might have been introduced by the intruder § For example, the Code Red II worm placed backdoors on compromised systems, and later the Nimda worm exploited those backdoors § A compromised system should be reformatted and reinstalled or restored from a known safe and trusted backup Planning ahead
Little analysis and lots of patching § Network administration must be kept informed of disclosed vulnerabilities § The environment should be standardized and well-documented § All changes must go through Changes Management § Every change must be tested at the testing environment § An automated process of patch installation may have the best cost/benefit
and Vulnerability Management Program § SP 800-115 § Technical Guide to Information Security Testing and Assessment § CVE § http://measurablesecurity.mitre.org/directory/areas/ vulnerabilitymanagement.html § ISO/IEC 29147:2014 § gives guidelines for the disclosure of potential vulnerabilities in products and online services. It details the methods a vendor should use to address issues related to vulnerability disclosure. § ISO/IEC 30111:2013 § gives guidelines for how to process and resolve potential vulnerability information in a product or online service.