US National Cybersecurity Emphasizes Need for Regulation; Enable GitHub Secret Scanning on All Libraries; Make Sure You Are Not Repeating Booking.com’s OAuth Misconfiguration

Two key points in this strategy: (1) Much more talk about regulation, but the US has a very poor record of ever actually passing meaningful federal cybersecurity regulation – witness 20 years of draft national privacy laws that never see daylight; (2) We have seen in the past that the government’s best leverage is through its buying power. To me, the most important thing this strategy says is “We will use Federal purchasing power and grant-making to incentivize security.” But, to be a nattering nabob of negativism: Here’s what President Clinton’s strategy said in 1998: “The Federal Government shall, through its research, development and procurement, encourage the introduction of increasingly capable methods of infrastructure protection.” Changing government procurement rules to require higher levels of security and testing of all products and services the government procures should be easier than getting politicians to agree – we have examples like FIPS 140-1 and FedRAMP of that being true, but need many more.

The much anticipated, National Cybersecurity Strategy has dropped. In many respects it’s a continuation of the 2018 Strategy. The primary differences being regulating critical infrastructure sectors; and, [potentially] shifting the liability burden from consumers to software vendors. On regulation, you can only do so much via executive order. If the strategy is to be fully implemented, the legislative branch will have to be involved. On shifting software liability, defining and measuring ‘secure by design’ is very complicated. Additionally, any liability changes will require action by Congress.

This strategy intends to level the playing field through more specific regulatory requirements to ensure consistent implementation. So long as a risk-based approach remains, this will get us where we need to be. These regulations, and corresponding guidance from NIST and CISA, should be tools the private sector can leverage in planning their cyber strategy. The biggest challenge is going to be how solutions and deployment teams are funded. While mention is made of federal buying power, consideration has to be given to implementation, process engineering, and mortgage costs.

We have to start somewhere but this strategy suggests the difficulty of this problem. We are in far worse shape, heavier reliance on technology, and more vulnerable than we were in the Clinton Administration. One might well like to see a strategy that stressed measurement. To paraphrase Thompson, "If one cannot measure it, one cannot recognize its presence or its absence," and Demming, "If you do not measure it, you cannot improve it."

Thanks Github for making this tool available for free. Github continues to lead in protecting open source developers by offering tools like this to free accounts.

Practitioner's note: Secret scanning will not turn on by itself. Per their blog post, "You can do this by going to the ‘Settings’ tab and clicking on ‘Code security and analysis’ under ‘Security’. Find ‘Secret scanning’ and click ‘Enable’."

Well done GitHub, choosing not to monetize security but rather, providing a security service for free to your users. Although a poor software development practice, developers often embed credentials (tokens, private keys) in their code. This service helps identify those credentials within the GitHub repository.

Uploading secrets to the repository can happen to anyone; I'll take any help I can get to make sure I don't mess up. This feature went beta back in December; it's now in production. That the service is free for all public facing repositories makes this a no-brainer - enable the scanning under Settings -> Code security and analysis (in the security section) click enable under Secret scanning. Discovered secrets trigger an alert to the contributor, repository admin and organization owners.

The article by Salt Labs is a good read for anybody implementing OAuth. The Booking.com use case is a bit different than what is usually done with OAuth, but still close enough that it is possible for others to fall into the same trap. It is nice to have the detailed walk through to learn from.

OAuth is an authentication standard that reduces credential theft by limiting application access to login credentials. It has seen increased usage over the past five years by website operators. As such, we’re seeing more and more attacks that take advantage of application misconfiguration to steal OAuth tokens. In this case, Salt Labs responsibly reported the misconfiguration but next time it may be an cybercriminal looking for a quick payout.

Note the response to the vulnerability disclosure, not only taking the input seriously but also quickly confirming they had not been compromised, then quickly resolving the issue, while acknowledging Salt Security for their report. I am sure we would prefer our own teams discover flaws, external discovery as a partnership rather than an adversarial action is a thing. If you don't already have a VDP policy, with supporting practices and possibly rewards, now is the time.

Good reading to base a desktop exercise around to make sure your breach responses will be more like the “Do-be’s” than the “Don’t be’s.”

This 8 minute read would be excellent homework before you gather to work your business continuity plan and exercise. Not only does this give you ideas about what sort of actions did or did not work, it's also food for thought when creating that tabletop exercise.

A good summary of incident response [in]action by several companies that suffered a cyber breach. The key takeaways from the article: 1) be responsible, bad news doesn’t get better over time; 2) be transparent to both employees and users; and 3) provide a post mortem on the attack to include where defenses failed.

Dish so far has made some of the common mistakes in handling a highly public incident like this: not communicating with customers, and allowing rumors based on insider leaks and incomplete releases as part of financial filings shape the story will hurt Dish's reputation more than the actual incident. I know people are likely busy dealing with the incident, but I also doubt that the PR team is helping remediate ransomware.

Note the statement from Dish below; it's not a bad starting point. Two things to note: First, there appear to be no updates since the 27th. Consider updates, with timestamps, to show you're not only working the problem but also aware of customer impact. Second, don't be afraid to be more transparent as to what the issue is. Indicators are that Dish had a data exfiltration/ransomware type of attack; most folks are aware of these attacks and what's involved to recover.

If you're running firmware version 12.0.1, you're not affected; if you're running a version older than 11.3.7SR1, you need to push the update. You may want to let your users know how to have their devices manually update, rather than rebooting their phone at an inopportune moment.

In any case, prefer purpose-built apps for sensitive applications, specifically to include finance, travel, and health.

You're going to need to download Decider and host it on your own server. The idea of the framework is by mapping the attackers’ behavior and progress, you're going to be better prepared to anticipate their next move, shutting down the attack. The problem is ATT&CK is complex, involved and tricky to use. Decider is positioned to simplify this using plain language that analysts at any level can understand. When things are going south, any help I can give my team is a win. Check this out before you're responding to an incident.

Kudos to CISA for simplifying the tedious task of mapping adversary attack behavior. It will be a handy aid for threat intelligence analysts to document attack patterns used by adversaries. Unfortunately, as we well know, many adversaries change their tactics and techniques given the target.

The healthcare sector continues to be a prime target for attack. Why is that. One reason is lack of resources (human, technology) available to properly secure its infrastructure. Another is security awareness training. Often security is an ‘additional duty as assigned’ for employees of small facilities that make up the bulk of the healthcare sector. We’ve got to simplify the secure implementation of IT applications for all.

The healthcare sector needs a little love here. They remain a popular target and regrettably they are a living example of life safety versus security; let alone costs. The last time I was in a hospital I was looking at all the equipment they have to deploy to remain current/viable, then consider the cost of the equipment, it was striking that they were as hard of a target as they are. The good news is organizations like Health-ISAC, CISA and others have resources they can leverage. I have contemplated asking my doctor, the next time I see him. if he needs help keeping his office secure. That may not be a bad opportunity for a little give-back.

These breaches suggest a flat network. We have been arguing here for structured and layered networks. More specifically, in healthcare we have suggested that clinical systems be isolated from the porous public network facing apps like e-mail and browsing. Similarly, servers should be isolated from the public networks. If it cannot be seen, it cannot be exploited.