Canadian Computer Emergency Response Team: Difference between revisions
(→IMMA) |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 2: | Line 2: | ||
https://www.opencert.ca | https://www.opencert.ca | ||
== Ideas == | |||
* API for attack detection submition ,open stadnards? XML RPC? | |||
* News feed? | |||
* vetting? | |||
* authentication | |||
* best practices library | |||
* ipv6 ? a la HE ( see [[ipv6]] | |||
* external testing: am I vulnerable to X? | |||
== IMMA == | |||
An approach: | |||
* Isolate | |||
* Minimize | |||
* Monitor | |||
* Active Defence | |||
By Mick Douglas @bettersafetynet | |||
=== Isolate === | |||
If you can, move impacted systems to a 'vulnerable VLAN'. | |||
If you can't do that, *carefully* review firewall rules between impacted hosts and the rest of your fleet. | |||
Another option is deploying a proxy firewall with deep packet inspection. | |||
=== Monitor === | |||
Start looking for odd traffic patterns to or from systems (even if they're not known) | |||
Some interesting things I've seen so far... Look for DMZ systems that INITIATE outbound connections. Typically your web servers RESPOND to requests. | |||
When attackers get shell access they will frequently have a phone home check... or are establishing a "reverse shell" (where your victim system calls back to them) | |||
This looks odd from a network layer because most internet facing systems respond to requests. | |||
Key word last tweet: MOST | |||
Some of your systems do initiate outbound comms. But these should be few. Even if you don't know which ones do/don't the odds are in your favor here. Your false positive rate should be low-ish. | |||
Start looking for outbound initiated connections now. | |||
We all hate change management, right? I know I do! This is a time it pays off. Look for unauthorized config changes on ALL systems. Some of these vuln log4j instances will be tucked away. When an attacker starts changing the host... you should see it. | |||
start looking for port/protocol mismatch. lots of the early attacks I've seen are using very old tricks to do recon in your network. In many cases, these are probes to common ports... but... they're not using the protocol. They're empty probes. Or just wrong. | |||
side note: you should be doing port/protocol mismatch checks anyway because it's a great detect for misconfigured systems or janky code. | |||
/end side note | |||
== Resources == | == Resources == | ||
| Line 8: | Line 59: | ||
* [http://www.cert.org/archive/pdf/11tr015.pdf Best Practices for National Cyber Security: Building a National Computer Security Incident Management Capability] | * [http://www.cert.org/archive/pdf/11tr015.pdf Best Practices for National Cyber Security: Building a National Computer Security Incident Management Capability] | ||
* [http://www.us-cert.gov/control_systems/practices/documents/final-RP_ics_cybersecurity_incident_response_100609.pdf Recommended Practice: Developing an Industrial Control Systems Cybersecurity Incident Response Capability] | * [http://www.us-cert.gov/control_systems/practices/documents/final-RP_ics_cybersecurity_incident_response_100609.pdf Recommended Practice: Developing an Industrial Control Systems Cybersecurity Incident Response Capability] | ||
* [http://www.sei.cmu.edu/reports/11tr015.pdf Best Practices for National Cyber Security: Building a National Computer Security Incident Management Capability, Version 2.0 ] | |||
[[category:security]] | |||
Latest revision as of 17:41, 15 December 2021
Overview
Ideas
- API for attack detection submition ,open stadnards? XML RPC?
- News feed?
- vetting?
- authentication
- best practices library
- ipv6 ? a la HE ( see ipv6
- external testing: am I vulnerable to X?
IMMA
An approach:
- Isolate
- Minimize
- Monitor
- Active Defence
By Mick Douglas @bettersafetynet
Isolate
If you can, move impacted systems to a 'vulnerable VLAN'.
If you can't do that, *carefully* review firewall rules between impacted hosts and the rest of your fleet.
Another option is deploying a proxy firewall with deep packet inspection.
Monitor
Start looking for odd traffic patterns to or from systems (even if they're not known)
Some interesting things I've seen so far... Look for DMZ systems that INITIATE outbound connections. Typically your web servers RESPOND to requests.
When attackers get shell access they will frequently have a phone home check... or are establishing a "reverse shell" (where your victim system calls back to them)
This looks odd from a network layer because most internet facing systems respond to requests.
Key word last tweet: MOST Some of your systems do initiate outbound comms. But these should be few. Even if you don't know which ones do/don't the odds are in your favor here. Your false positive rate should be low-ish.
Start looking for outbound initiated connections now.
We all hate change management, right? I know I do! This is a time it pays off. Look for unauthorized config changes on ALL systems. Some of these vuln log4j instances will be tucked away. When an attacker starts changing the host... you should see it.
start looking for port/protocol mismatch. lots of the early attacks I've seen are using very old tricks to do recon in your network. In many cases, these are probes to common ports... but... they're not using the protocol. They're empty probes. Or just wrong.
side note: you should be doing port/protocol mismatch checks anyway because it's a great detect for misconfigured systems or janky code. /end side note
