In Wake of CSRB Report, Microsoft is Enhancing Their Secure Future Initiative; RSA: White House Looking to Shift Burden of Software Liability to Manufacturers; 78-Month Prison Sentence for Selling Counterfeit Cisco Equipment

This is a big deal for two reasons. In 2002, Bill Gates revolutionized Microsoft's priorities with Trustworthy Computing. Over the past two decades in many ways the Windows operating system has become the standard for building security into default configurations. Satya Nadella's SFI is the same thing, but instead of building security into operating systems MS is embedding security into organizational culture. This is very exciting as I think they will actually do it. It's going to take years to truly see the change organization-wide, but sense of urgency and mission is there long term. But the second, and even more important take away is the impact CSRB can have. If they continue to publish detailed breach reports like this (hint: United Healthcare), we may begin to see the root causes (culture) and change that industry wide.

Microsoft has published a roadmap to show how they are meeting 20 of the CSRB recommendations, including victim notification, which is not getting as much attention as their other activities. Even so, make sure that you're following current guidance securing your Microsoft environments, managing accounts and permissions. Double check your implementation of strong authentication and that your team knows how to find and access the detailed logs of activity.

While a welcome move, it is deeply disappointing that it took a breach and the CSRB report for Microsoft to take these steps. The products and services we rely on should already be built with the principles outlined above. One has to wonder how many other vendors are not focusing on security and will only do so in response to a breach of their products/services.

Microsoft has added some very key promises to SFI and backed it with a memo from Microsoft CEO Satya Nadell to all MSFT employees that said In some cases, this will mean prioritizing security above other things we do, such as releasing new features or providing ongoing support for legacy systems. This is key to advancing both our platform quality and capability such that we can protect the digital estates of our customers and build a safer world for all. Two things to cynically point out: (1) Why only in some cases?? and (2) the annual RSA conference is to these kinds of promises as New Year's Day is to resolutions: if in some cases you still eat those deep-fried chocolate-filled croissants, you likely are not going to lose weight or avoid heart attacks.

The peddling of counterfeit network equipment has been around for decades. The easy solution is to buy directly from the equipment vendor or one of its resellers. That said, federal statutes can require that a percentage of procurement dollars be set aside for small business bidding. That's enabled individuals like Mr. Aksoy and his multiple companies to market in counterfeit equipment and cheat the system for personal gain. Kudos to law enforcement, keep up the good work.

This is old school supply chain security failure and this particular flavor (counterfeit Cisco products) has been going on for 15 years Ð in 2009 DoJ prosecuted two people caught selling counterfeit Cisco gear to the Federal Bureau of Prisons. The security principle violated is basic common sense: if it seems too good to be true, it probably isn't. Simple table-top exercise: see if you can get procurement to agree to buy all CXOs Roleks watches that are selling NOW for $49.95.

Cisco, US CBP and others have been working to shut down his shipment of counterfeit Cisco equipment. The question is could your team spot counterfeit equipment? Are you checking? This actor was hiding behind multiple personas running about 15 businesses, albeit all operating out of the same warehouse. If you're buying directly through resellers, DSB or otherwise, make sure you're vetting your suppliers and their deliveries carefully, particularly boundary control and other security devices. If you don't know how or if this is done, find out.

It's easy to say we're shifting the liability burden to manufacturers and yes, they can do much, much more to strengthen secure by design principles. That said, eliminating design level vulnerabilities is a difficult task and will require knowledge and skills that aren't easily taught by software developers. Another consideration is that years of research has proven it nearly impossible to eliminate all vulnerabilities, design, and implementation level in commercial software. In its present form, the only winner with this approach is liability lawyers.

Making sure that suppliers have skin in the game when it comes to secure software will, I hope, help raise the bar across the board. One aspect that has to be considered is the exploitability of flaws, particularly of embedded code or libraries from third parties. Software suppliers already prioritize flaws which can be exploited to make keeping complex packages manageable.

This is like talking to the deep-fried chocolate croissant industry about nutrition. The federal government needs to talk via its buying power Ð the software industry and its lobbying firms have been effectively immune to talks about taking ownership of even easily avoided flaws in their products.

One would like to see the software industry meet the same standard of merchantability as any other industry and that the Administration would follow through on what is so far only a threat. However, the market's tolerance for shoddy and the industry culture of "ship early, add quality late" is so deeply entrenched that one cannot be very hopeful.

The fix is to update to the patched version of ArubaOS 8.10, 8.11, 10.4, 10.5 or 10.6. If you're not on one of these versions to begin with, you need to get there. While there are workarounds, they don't address all the issues in all the ArubaOS versions; the safer bet is to update rather than stopping the sand running through your fingers.

It's crucial that every network vendor is part of this conversation. The widespread nature of this network vulnerability demands immediate action-patching is essential. We often encounter such fundamental issues during penetration tests. However, many testers lack deep network knowledge and the necessary exploits. It's a risk not worth taking.

Practitioner's note: for defenders who currently track name resolution by inspecting port 53/TCP/UDP traffic at the network edge, you'll need to shift focus to the endpoint or the protective DNS servers. The latter assumes you're running your own or have access to telemetry from your protective DNS provider.

This aligns with OMB M-22-09 and NIST SP 800-207 to support DOH/DOT as well as integration with the Windows firewall for DNS traffic routing, allowing you to filter out undesired domain or even upstream resolvers, not unlike the PDNS service CISA provides agencies. The goal is to have all DNS traffic encrypted and only use trusted servers. Once you have DOH/DOT servers in place, you're going to want to focus on client mods to use DOH/DOT, including routing that traffic to your trusted servers.

Practitioner's note: this is an easy one to check. Perform a web search for "dmarc checker," enter your domain, and see what it says. Getting it right can be tricky, but the first step is knowing whether you're vulnerable.

If you don't have a DMARC setting, or your policy is set to none (p=none) it's time to change it to reject or quarantine, with a 100% applicability. Yeah, rolling out DMARC with a p=none was safe, it accepts all messages, and as such, isn't effective. Make sure to communicate as you change this setting. The bulletin also gives guidance on how to read the email headers to see how your SPF, DKIM and DMARC settings are being applied.

One often implements new controls with a permissive policy to avoid disruption, with the full intentions of moving to a more restrictive policy that one fails to get around to. My mentor, Charlie Middleton, taught me to over-control new applications; one can always relax the controls later if warranted. However, once the application gets out of control, tightening may be too late to be effective.

It's a simple math problem for the telco providers. Stay in the program and get stuck with 60% of the bill or withdraw and not realize a one-time 30-ish% increase in revenue. I suspect many will exit the program unless Congress comes through with the full funding amount. The question then becomes whether government will move to shut down those networks in violation of the law and deny connectivity to rural users.

Small carriers, with 2 million customers or fewer, were given priority for this funding, and it is estimated that the awarded funds still only covered about 40% of the replacement equipment cost and that an additional 3.9 billion is needed to correct the problem. In MondayÕs RSA keynote from Secretary of State Blinken, he stated a commitment to not let US suppliers lag in technology to prevent a repeat occurrence of this scenario.