Compliance

Usually my blog posts are focused on the arguably mundane practices of cybersecurity governance. Today, though, I would like to get into something a bit spicier. Right now, as I write this, Russia has about 90,000 troops amassed at the Ukrainian border, and China has been harassing Taiwanese airspace for months. Some kind of aggressive action, possibly cyber-related, seems very possibly forthcoming; and with it, likely a response in kind.
 
It’s a known fact that Russia, China, North Korea, Iran and others engage in regular cyber attacks against the other countries including the US. We see this all the time. What I think is unclear to most people are the rules governing the responses to such attacks. Below I discuss a broad overview of how cyber attacks are handled by governments around the world.
 
First off, you should know that the international law around the rights self defense of a state actor is extremely murky and highly disorganized. Furthermore, different countries disagree on the interpretation of laws that exist. That being said, there are some general rules that are followed by responsible governments.

One regulation we help clients with is the New York State DFS 23 NYCRR Part 500 compliance.
 
Who does DFS regulate?

According to its website: “DFS is the primary regulator for all state-licensed and state-chartered banks, credit unions, and mortgage bankers and brokers. All mortgage loan servicers doing business in New York State must be registered or licensed by DFS. The Department also oversees all of the insurance companies operating in New York, licenses all of the budget planners, finance agencies, check cashers, money transmitters, and virtual currency businesses operating in New York.”
 
The requirements of part 500 are generally nothing out of the ordinary, or rather, nothing more than what is already considered good practice in the cybersecurity world.

POSITION ON RISK

1. Initial risk is 100% (99.9%). I argue, if you deploy a system without any controls and connect it to the internet, it will be hacked multiple times in a year.
2. Risk = 100% - control mitigation + destabilizing events (zero days, new vulnerabilities).
3. We may calculate control mitigation but cannot predict those destabilizing events, and this is the nature of the business, and this is why we cannot precisely measure risks. So we don't have to; we can just assess.
4. Mitigation is NOT lowering the impact but lowering LIKELIHOOD. When there is a cybersecurity breach, it is easier to predict maximum impact, which depends on the time of detection (controls - destabilizing). I would argue that within some short time, the impact could be the cost of the business. 
5. My biggest problem with current frameworks is that they all concentrate on initial assessment, not the continuous process.
6. Risk has to be re-assessed yearly, and the methodology is more important for re-assessment compared to the initial assessment.
7. Incidents should be used to adjust risks as it is real-life data for statistical analysis for the given client. Incidents should be used to re-assess likelihood, and each incident must be bound to a risk and effect KPI.
8. Methodology should suggest KPI assignment. 

This is the big picture. All I see today is ISO-like risks analyses that are initially made based on industrial risks. The mentality should be changed, and I don't know if it is too big of a shift from the current approach.