Statement by President Biden: What you need to do (or not do)

Statement by President Biden: What you need to do (or not do)
Yesterday, President Biden released a statement warning of a possible escalation of cyberattacks from Russia. The statement does not offer a lot of specifics. But it does link to two valuable documents: Fact Sheet: Act now to protect against potential cyberattacks. CISA "Shields Up" site. So what does this mean for you? What should you do (or not do), and what kind of attack should you expect? The answers depend in part on your organization. If you are part of a government network (or contractor) or part of critical infrastructure: Reach out to your specific ISACs or other information-sharing organizations if any details are available. For everybody else: Keep reading. Let me first mention a few things that will not help: Blocking all traffic from Russia (and Belarus) "Random" blocklists are unlikely going to block the attack. It may be helpful for other purposes, for example, if you no longer would like to do business with these countries or to "cut down the noise" as you may see some politically motivated nuisance scans from these countries. The same may be true for other countries. Double-check that there is no legitimate need for access from these countries. Starting a major security initiative and rushing it to "be ready" (like rolling out MFA by the end of the week). This is not the time to make significant, rushed changes to the network. If anything, you want to reduce your workload at this point to have capacity if something terrible happens. This is true for any significant (disruptive) change. A change freeze may be worth considering in some cases. Sending a lot of updates to staff and management about what should/should not be done. Again: Do not add to the noise. If there is something actionable to communicate and share: Share! But this isn't the time to send lengthy emails reminding people of impending doom if they click on an attachment. They either know not to by now, or your email will not make a difference. Things you should do: Keep senior leadership informed (if you are leading the team/security department) One purpose of a presidential statement is to raise awareness. Non-tech news outlets widely covered this statement, and your boss or boss's boss likely heard about it and may have questions about how you or your team are preparing. Have a brief ready to keep them informed. Use the "Fact Sheet" above, and explain how you address the controls the fact sheet mentions. Be honest, show that you got the issue under control, and outline what may be missing (and how they can help, for example, by providing resources). With a high visibility announcement like this, there may be a lot of pressure to "do something." Make sure what you are doing makes sense. This kind of management pressure can often become a DoS attack against your staff. Avoid it by having answers ready for senior management. This isn't the time to do "something." But to do things that make sense, that are planned, and things that fit into your larger security strategy. Avoid busywork The statement is vague and does not contain any specific information about what threat to expect. Avoid keeping your team busy with "double-checking" or "rescanning" things they just recently did. Trust your team. If anything, encourage them to take a day off now. Whatever will happen (if it happens) will likely happen soon, and you need a rested team to work the extra hours once the attack hits. Now is not the time for long hours and overtime. Review recent events The best you can do is look at recent events in Ukraine and review the TTP associated with them. For the most part, wipers were used in an attempt to disrupt networks. They typically didn't use any new vulnerabilities to enter the network. In addition, a denial of service attack is a likely scenario. Share! Share what you are seeing. Some things may not make much sense to you, but with the help of others may solve your puzzle and help them understand theirs. --- Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu Twitter\| I will be teaching next: Application Security: Securing Web Apps, APIs, and Microservices - SANSFIRE 2022	Johannes 4505 Posts ISC Handler Mar 22nd 2022
Thread locked Subscribe	Mar 22nd 2022 3 months ago
Indeed, sharing information on attacks seems like a good idea. For the past few weeks, I have been working on my own IDS/honeypot software, which tracks SSH and web intrusion attempts and shares the data with ISC's own 404 Web Honeypot project (SSH still to come, possibly, if I can figure out the format. I just noticed ISC does that too), as well as with some other services like AbuseIPDB (SSH too, there).	Vincent T 16 Posts
Quote	Mar 23rd 2022 3 months ago
While I agree that block-by-country firewall rules won't prevent you from being attacked, using some of the public lists of IPs/CIDRs of known bad-actors can do something useful. When I upgraded the home firewall (opnsense) and enabled rules for the CINS Bad Guys and some of the ET (emerging threats) lists, most of the attack traffic I saw on a day to day basis dried up. This lowers the volume of background noise your IDS/NIDS systems have to go through and log. I actually wound up using this as an excuse to spin up some honeypots because I was in the middle of testing some log analysis modules for a syslog daemon I wrote and needed some more interesting attack traffic. Yeah, I'm a geek and probably need to seek help. And speaking of honeypots, spinning them up in an externally facing network segment can be interesting if you want to look at who's scanning for what today, but is probably not terribly useful. But spinning up honeypots in your interior networks and sprinkling around some breadcrumbs leading an attacker to the honeypots (cached credentials, exciting DNS hostnames like fbi-vpn-gw.mydomain, or scada-gw.mydomain, etc) CAN be useful, especially if you log everything. Which brings me to the final thing this diary post reminded me of... Logging! At a previous job I had very little budget for cybersecurity and was having to build a security infrastructure from the ground up. So instead of spending boatloads of cash I didn't have on a proper SIEM, I spent it on endpoint protection/detection, intrusion detection, and better logging, analysis, and visualization tools. If your logs are complete and you have decent visualization tools you can do a lot of what SIEMs do, albeit manually - we humans are good at spotting anomalies visually, but not so great at reading gigabytes of logs. So now might be a good time to setup new visualizations of your log data. I found that my visualizations of log data (ie, hits on DNS RPZ filters, or egress firewall filters) and looking at those charts at least daily led me to making better log analysis rules, which uncovered more interesting data in the logs, which led to making new ways to graph/diagram the logs to visually detect some new sort of event, which led back to find new things in the logs and making more/better visualizations, etc. Anyway, just a thought or three...	Brent 133 Posts
Quote	Mar 23rd 2022 3 months ago
> Indeed, sharing information on attacks seems like a good idea. Honeypots can be interesting! I was disappointed to find that the FTP/ssh/CIFS honeypots I spun up only netted about four or five different strains of malware to pick apart though. (though I would see a gazillion different copies of that handful of malware) I wrote a syslog daemon with some rudimentary log analysis features so I tweaked it to watch for certain types of attack activity (or people poking at the honeypots) and had it update the firewall to block the offending IP for X days, just out of curiosity. It meant that 3rd party relay or brute force auth attacks on a mailserver (for instance) are quickly squelched, but I didn't see a lot of repeat attacks from IPs seen in previous days.	Brent 133 Posts
Quote	Mar 23rd 2022 3 months ago

Yesterday, President Biden released a statement warning of a possible escalation of cyberattacks from Russia. The statement does not offer a lot of specifics. But it does link to two valuable documents:

Fact Sheet: Act now to protect against potential cyberattacks.
CISA "Shields Up" site.

So what does this mean for you? What should you do (or not do), and what kind of attack should you expect? The answers depend in part on your organization.

If you are part of a government network (or contractor) or part of critical infrastructure: Reach out to your specific ISACs or other information-sharing organizations if any details are available. For everybody else: Keep reading.

Let me first mention a few things that will not help:

Blocking all traffic from Russia (and Belarus)
"Random" blocklists are unlikely going to block the attack. It may be helpful for other purposes, for example, if you no longer would like to do business with these countries or to "cut down the noise" as you may see some politically motivated nuisance scans from these countries. The same may be true for other countries. Double-check that there is no legitimate need for access from these countries.
Starting a major security initiative and rushing it to "be ready" (like rolling out MFA by the end of the week).
This is not the time to make significant, rushed changes to the network. If anything, you want to reduce your workload at this point to have capacity if something terrible happens. This is true for any significant (disruptive) change. A change freeze may be worth considering in some cases.
Sending a lot of updates to staff and management about what should/should not be done.
Again: Do not add to the noise. If there is something actionable to communicate and share: Share! But this isn't the time to send lengthy emails reminding people of impending doom if they click on an attachment. They either know not to by now, or your email will not make a difference.

Things you should do:

Keep senior leadership informed (if you are leading the team/security department)
One purpose of a presidential statement is to raise awareness. Non-tech news outlets widely covered this statement, and your boss or boss's boss likely heard about it and may have questions about how you or your team are preparing. Have a brief ready to keep them informed. Use the "Fact Sheet" above, and explain how you address the controls the fact sheet mentions. Be honest, show that you got the issue under control, and outline what may be missing (and how they can help, for example, by providing resources).

With a high visibility announcement like this, there may be a lot of pressure to "do something." Make sure what you are doing makes sense. This kind of management pressure can often become a DoS attack against your staff. Avoid it by having answers ready for senior management. This isn't the time to do "something." But to do things that make sense, that are planned, and things that fit into your larger security strategy.
Avoid busywork
The statement is vague and does not contain any specific information about what threat to expect. Avoid keeping your team busy with "double-checking" or "rescanning" things they just recently did. Trust your team. If anything, encourage them to take a day off now. Whatever will happen (if it happens) will likely happen soon, and you need a rested team to work the extra hours once the attack hits. Now is not the time for long hours and overtime.
Review recent events
The best you can do is look at recent events in Ukraine and review the TTP associated with them. For the most part, wipers were used in an attempt to disrupt networks. They typically didn't use any new vulnerabilities to enter the network. In addition, a denial of service attack is a likely scenario.
Share!
Share what you are seeing. Some things may not make much sense to you, but with the help of others may solve your puzzle and help them understand theirs.

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

I will be teaching next: Application Security: Securing Web Apps, APIs, and Microservices - SANSFIRE 2022

Johannes

4505 Posts
ISC Handler

Mar 22nd 2022

Indeed, sharing information on attacks seems like a good idea. For the past few weeks, I have been working on my own IDS/honeypot software, which tracks SSH and web intrusion attempts and shares the data with ISC's own 404 Web Honeypot project (SSH still to come, possibly, if I can figure out the format. I just noticed ISC does that too), as well as with some other services like AbuseIPDB (SSH too, there).

Vincent T

16 Posts

While I agree that block-by-country firewall rules won't prevent you from being attacked, using some of the public lists of IPs/CIDRs of known bad-actors can do something useful. When I upgraded the home firewall (opnsense) and enabled rules for the CINS Bad Guys and some of the ET (emerging threats) lists, most of the attack traffic I saw on a day to day basis dried up. This lowers the volume of background noise your IDS/NIDS systems have to go through and log. I actually wound up using this as an excuse to spin up some honeypots because I was in the middle of testing some log analysis modules for a syslog daemon I wrote and needed some more interesting attack traffic. Yeah, I'm a geek and probably need to seek help. :-)

And speaking of honeypots, spinning them up in an externally facing network segment can be interesting if you want to look at who's scanning for what today, but is probably not terribly useful. But spinning up honeypots in your interior networks and sprinkling around some breadcrumbs leading an attacker to the honeypots (cached credentials, exciting DNS hostnames like fbi-vpn-gw.mydomain, or scada-gw.mydomain, etc) CAN be useful, especially if you log everything.

Which brings me to the final thing this diary post reminded me of... Logging! At a previous job I had very little budget for cybersecurity and was having to build a security infrastructure from the ground up. So instead of spending boatloads of cash I didn't have on a proper SIEM, I spent it on endpoint protection/detection, intrusion detection, and better logging, analysis, and visualization tools. If your logs are complete and you have decent visualization tools you can do a lot of what SIEMs do, albeit manually - we humans are good at spotting anomalies visually, but not so great at reading gigabytes of logs. So now might be a good time to setup new visualizations of your log data.

I found that my visualizations of log data (ie, hits on DNS RPZ filters, or egress firewall filters) and looking at those charts at least daily led me to making better log analysis rules, which uncovered more interesting data in the logs, which led to making new ways to graph/diagram the logs to visually detect some new sort of event, which led back to find new things in the logs and making more/better visualizations, etc.

Anyway, just a thought or three...

Brent

133 Posts

> Indeed, sharing information on attacks seems like a good idea.

Honeypots can be interesting! I was disappointed to find that the FTP/ssh/CIFS honeypots I spun up only netted about four or five different strains of malware to pick apart though. (though I would see a gazillion different copies of that handful of malware)

I wrote a syslog daemon with some rudimentary log analysis features so I tweaked it to watch for certain types of attack activity (or people poking at the honeypots) and had it update the firewall to block the offending IP for X days, just out of curiosity. It meant that 3rd party relay or brute force auth attacks on a mailserver (for instance) are quickly squelched, but I didn't see a lot of repeat attacks from IPs seen in previous days.

Brent

133 Posts