Please enable JavaScript.
Coggle requires JavaScript to display documents.
Enterprise Threat- Vulnerability Assesment - Coggle Diagram
Enterprise Threat- Vulnerability Assesment
Need to VA at scale
Yet finding & mitigating vul across ten thousand up to millions of systems is a daunting task. Its not just finding one flaw on one system. Finding & fixing vul on handful of machines can be relatively easy but doing this as scale of 10,000 or more system requires a thorough methodology, purposeful automation, and proper strategies & tactics.
The result is comprehensive V management program
To defend themselves at scale, enterprise organization must have consistent, automated vulnerability management prog
Majority of the recent large-scale breaches began with the exploitation of an unpatched software vulnerability. If only the org had the patch in place, the breach may have been prevented. Why didn't they? what stopped them from applying that one patch that one system that proved to be their downfall?
Objective
Learn how to verify discovered vul- false positive reduction & false negative identification, all the while considering the business risk posed by discovered flaws
Learn processes for enumerating systems & their vulnerabilities at scale across a variety of types of org.
Intensively focused on finding flaws & validating them, across a broad scale, using automation to achieve speed & efficiencies
Go RedBlue
Enterprise Threat & VA
As the time goes on, enterprise IT is becoming more complex. This is mainly due to the increased business functionality That the org depends on. As we move toward more business functionality & processes on the network, we have made the infra & apps more complex & difficult to test
Intro if new technolo has increased the dificulty in understanding dependence's & security implications - more sec - new sec defensive tec
Sec assessor have to understand this new complexity & tec wrapped around it - sometimes new types of vul - some times same old vul in new contexts
Understanding how exploitation works helps sec. VA is an extension of performing threat modeling. If somone were to target your org. what assets would they be after, and what vul would most likely lead to successful compromise?
"The engine which drives enterprise is not Thrift, but Profit". - John Maynard Keynes
Reasons to perform VA
How to asses your own sec, How to assure management that sec is appropriate. Meeting risk tolerance req.
How can admin evaluate the state of sec in enterprise env becomes an imp question
How can mgmt be assured that their sys,apps sec meet theor requirements as well as risk tolerance is another
Know yourself & know your adversary 'Know your enemy'
Through analysis of offensive techniques, we can learn to better defend ourselves.Armed with knowledge with tools & tec used to attack we can build better defensive sys & protect org assets
Architecting for security on purpose
Logging & active monitoring should let us know when something improper such as misuse or an intrusion might have occurred
In order to defend a nw, you should know everything there is to know about it.preferably before an intruder does
penetration testing- ultimate goal of the entire endeavor would be to plan & perform a comprehensive docs of the entire infra
Layered defense strategy- properly prevents or deters attackers from gaining access to sensitive info
Design better architectures- sys/nw sec should be designed & properly implemented by ground-up
Designing Security
Assume that Security is not a static achievable state, but a moving process that must be maintained over time
There is no magical silver bullet to solve all sec problems, however Vul testing is a key element in an overall sec prog for any org
Sec process is all abt applying the appropriate policies through proper procedures & mgmt practices
Issue with VA is that they are are 'snapshot in time'
of a sys or nw sec posture. As such, testing is limited to know vul & the current config of nw.
We must move towards a continuous assessment positive feedback loop.
Key to security is, of course, always policy
. Without coherent set of policies, it really isnt possible to ever be 'secure'.
Policies must be statement of managements intent.
Definitions
Security Audit
assess the adequacy of the controls & evaluate compliance
Vulnerability assessment
Description & analysis of the vul in a system
Vulnerability
Flaw or weakness in the system that can be exploited
"The quality or state of being exposed to the possibility of being attacked or harmed, either physically or emotionally"
Penetration testing
Circumvent the sec features of a system to demonstrate risk
Vulnerabilities
A lack of control, policies,procedures , or documentation can also be considered a vul, something that should be addressed.
Very imp considerations for any vul are: Who can access it? How visible is the system /application
Not abll Vul are tec. People can be more or less vul to exploitation- vul to social engineering
Lack of segmentation or overly permissive access control can also be considered a vul.
To be exploited access or visibility is required
Why implement VA prog
Merger / Acquisition
Baseline an environment
Compliance/Audit - (GDPR, ISO27001 , PCI-DSS, GLBA, Sarbanes Oxley, HIPAA
Critical control #7 Continuous VA & remediation
VA Framework
There are many methodologies available to be considered, NIST PTES,FISMA, Penetration testing framework
Introduce the VA methodology, 7 phase
engagement planning
Threat Modeling
Discovery
Scanning
5.Validation
Remediation
Reporting
last 3 can be iterative loop- Reporting loops back to engagement planning
The key is not running scanners, but analysis, correlation , documentation, & problem solving. - key is analysis & DB utilization
1. Engagement planning
Rules of engagement
Scoping
Logistics & planning are arguably the second most imp part of any enterprise scale task, the most imp being reporting
Process, procedure, checklists
Access & visibility
Scanner architecture , risk accpetance
2. Intelligence & threat modelling
What are their most likely target/critical assets/functions?
What are the most probable & likely to succeed attack vectors?
Who are the most likely threat sources/actors?
How likely are the mitigation controls able to detect/respond?
Level of sophistication & resources required to pull attacks off
Identify & prioritize what are the most likely threats the org or specific assets may face
Gathering Intelligence
Now you have a threat model, develop a roadmap to mitigate
3. Discovery
Outputs: Whois, DNS, IP Addresses or hostnames of systems which are likely to be live.
Tools: PIng, Nmap, lke-scan, Fierce Doman Scanner, traceroute, ICMP
Inputs: URLs, hostnames, domain names, IP addresses, or ranges
Data types: text files, XML files
Purpose: determine which systems are live & map the NW
4. Scanning
Outputs: Listing of potential vulnerabilities
Tools: Scanners such as Nessus, Nexpose, Burp, W3AF
Inputs: IP addresses, ports, services, applications
Data types: text files, XML files, databases
Purpose: identify known or unknown vul in the identified technologies
Manjor considerations are scanner placement & impediments to testing, such as FWs & LB
The testing must reflect the overall sec roadmap & provide actionable results along with metrics
5. Validation
5 more items...
Vulnerability Criticality
Our criticality determination process is based on the OWASP risk rating methodology where risk = likelihood * impact
High
: The impact of exploitation is high, and the probability of occurrence is high
Political: Vul does exist, but will not be mitigated
Medium
: The impact of exploitation is medium & the probability of occurrence is medium. Or high impact, low probability
Unknown- The vul does exist but exploitation is non-trival
Low
: The impact of exploitation is low, & the probability of occurrence is low
Asset classification
There are 3 approaches:
Data classification
Asset based on server criticality
System funct based & dependencies
In order to determine impact of risk assessment we need to have an asset or functionality criticality methodology