Category: CERT

Categories
CERT

A classification of CTI Data feeds

(Crossposted on the CERT.at blog.)

I was recently involved in discussions about the procurement of Cyber Threat Intelligence (CTI) feeds. This lead to discussions on the nature of CTI and what to do with it. Here is how I see this topic.

One way to structure and classify CTI feeds is to look at the abstraction level at which they operate. As Wikipedia puts it: 

  • Tactical: Typically used to help identify threat actors (TAs). Indicators of compromise (such as IP addresses, Internet domains or hashes) are used and the analysis of tactics, techniques and procedures (TTP) used by cybercriminals is beginning to be deepened. Insights generated at the tactical level will help security teams predict upcoming attacks and identify them at the earliest possible stages.
  • Operational: This is the most technical level of threat intelligence. It shares hard and specific details about attacks, motivation, threat actor capabilities, and individual campaigns. Insights provided by threat intelligence experts at this level include the nature, intent, and timing of emerging threats. This type of information is more difficult to obtain and is most often collected through deep, obscure web forums that internal teams cannot access. Security and attack response teams are the ones that use this type of operational intelligence.
  • Strategic: Usually tailored to non-technical audiences, intelligence on general risks associated with cyberthreats. The goal is to deliver, in the form of white papers and reports, a detailed analysis of current and projected future risks to the business, as well as the potential consequences of threats to help leaders prioritize their responses.

With tactical CTI, there a reasonable chance that it can shared on a machine-to-machine basis with full semantic information that makes it possible to automate the processing for detection and prevention purposes. Many commercial security devices are sold with a subscription to the vendor’s own data-feeds. This ranges from simple anti-spam solutions, over filters for web proxies to rules for SIEMs.

While it is possible to encode operational CTI in standardized data exchange formats like STIX2, it is much harder for automated systems to operationalize this information. For example, what automated technical reaction is possible to “threat actor X is now using compromised CPEs in the country of its targets for C2 communication”? Yes, one can store that kind of information in OpenCTI (or a similar Threat Intelligence Platform (TIP)) and map it to the ATT@CK framework. That can be valuable for the human expert to plan defenses or to react better during incidents, but it is not detailed enough automated defense.

With strategic CTI, we are on the human management layer. This is never designed for automated processing by machines.

Types of IOCs

Focusing on the technical layer, we find that there are a number of different types of information encoded in the data feeds. One way to look at this is the Diamond Model of intrusion analysis which is built around information on adversary, capability, infrastructure, and victim. While this is a very valuable model for intrusion analysis, it is too complex for a simple categorization of CTI feeds.

I propose the following three basic types:

Type 1: Attack Surface Information

Many of the feeds from Shadowserver fall in this category. Shodan data can also be a good example. There is now a bunch of companies focusing on “cyber risk rating”, which all try to evaluate the internet-visible infrastructure of organizations.

Examples:

  • “On IP-address A.B.C.D, at time X, we detected a Microsoft Exchange server running a version that is vulnerable to CVE-202X-XXXX”.
  • “The time-server at IP addres Y can be abused as ddos-reflector.”
  • “On IP address Z, there is an unprotected MongoDB reachable from the Internet.”

Notable points are:

  • This is very specific information about a concrete system. Usually, it is very clear who is responsible for it.
  • There is no information about an actual compromise of the listed system. The system might be untouched or there may already be a number of webshells deployed on it.
  • There is no information about an attacker.
  • This is sensitive (potentially even GDPR-relevant) information.
  • This information is (almost) useless to anybody but the owners of the system.
  • Thus, the coordinating CSIRT should pass this information on to the maintainers of this system and to nobody else. CERT.at is usually tagging these events with “vulnerable / vulnerable system” or “vulnerable / potentially unwanted accessible service”.

Expected response from system owner: 

  • Mitigate the threat by patching / upgrading / removing the system or maybe even accept the risk (e.g. “yes, we really want to run telnet enable on that server”).
  • Verify that the system has not been breached yet.

Type 2: Threat Actor IOCs

This is the opposite: the information is solely about the threat actor and the resources this group is using, but there is no clear information on the targets. Typical information contained in these IOCs is:

  • The domain-name of a command & control (C2) server of the TA
  • An IP address of a C2 server
  • Filename and/or hash of malware used by the TA
  • Email subject, sender and sending IP address of a phishing mail
  • Mutex names, registry-keys or similar artefacts of an infection
  • URL-pattern of C2 connections

Example:

  • A RAT Remcos campaign was detected 2023-06-14 to use
    • Mutex: Rmc-MQTCB0URI: /json.gp
    • Email-attachment: Shipment_order83736383_document_file9387339.7z
    • MD5: 2832aa7272b0e578cd4eda5b9a1f1b12
    • Filename: Shipment_order837363.exe

Notable points are:

  • This is detailed information about a threat actor infrastructure, tools and procedures.
  • There is often no information about targets of these attacks. Sometimes, some targeting information is known, like “This TA usually attacks high-tech companies”.
  • This information is potentially useful for everybody who that actor might target.
  • Unless one thinks that attacker IP-addresses deserve GDPR-protection, this data has no privacy implication.
  • Thus, the coordinating CSIRT should pass this information on to all constituents who are capable of operationalizing such CTI. CERT.at is usually not sending this kind of information pro-actively to all constituents, instead we operate a MISP instance which holds these IOCs. Security automation on the side of the constituent is welcome to use the MISP APIs to fetch and process the IOCs.
  • If the targeting of the TA is sufficiently well known and specific, CERT.at will pass on the IOCs directly to the constituent’s security team.
  • In rare cases, the TA is abusing infrastructure of one of our constituents. In that case, we have a mix with the next type of CTI.

Expected response from system owner:

  • Add the IOCs to any sort of incident prevention system, e.g., filter lists in proxies, EDR or AV software.
  • Add the IOCs to the incident detection system, e.g., create suitable rules in SIEMs.
  • Ideally, also perform a search in old logs for the newly acquired IOCs.

Type 3: Infection data

Sometimes we receive cyber threat information that is very specific and concerns a live incident inside a constituent’s network.

Examples are:

  • “We detected at timestamp X a webshell placed on a Citrix server. IP-address = A.B.C.D, path = /logon/LogonPoint/uiareas/mac/vkb.php”
  • “Our darknet monitoring detected that someone is selling VPN credentials for user@example.com on the platform X”
  • “After a takedown of botnet X we are monitoring botnet drone connections to the former C2 servers. On [timestamp], the IP address A.B.C.D connected to our sinkhole.”
  • “We managed to get access to the infrastructure of threat actor X. According to the data we found there, your constituent Y is compromised.”
  • “Please find below information on IPs geolocated in your country which are most likely hosting a system infected by SystemBC malware. […] Timestamp, IP-address, hostname, c2 ip-address”
  • “There are signs of malicious manipulations on the Website of domain X, there is a phishing page at /images/ino/95788910935578/login.php”

Notable points are:

  • This is usually very specific information about a live incident involving a concrete system.
  • In the best case, the information is good enough to trigger a successful investigation and remediation.
  • The threat actor is often, but not always, named.
  • This is sensitive (potentially even GDPR-relevant) information.
  • This information is (almost) useless to anybody but the owners of the system.
  • This information can be very time-sensitive: a quick reaction can sometimes prevent a ransomware incident.
  • Thus, the coordinating CSIRT should pass this information quickly on to the maintainers of this system and to nobody else. CERT.at is usually tagging these events with “intrusions / system-compromise” or “fraud / phishing”

Expected response from system owner:

  • Start the local incident response process.
  • Clean up the known infection and investigate the possibility of additional compromises in the affected network (lateral movement?).

Tooling

CERT.at is using IntelMQ to process feeds of type 1 and 3. CTI feeds of type 2 are handled by our MISP installation.

Categories
CERT Internet

Boeing vs. Microsoft

2019: Boeing uses a single “angle of attack” sensor to control the automatic pitch control software (MCAS). A software upgrade to use both AOA sensors was sold as an optional extra. Result: two planes crashed, killing 346 people. The damages and the subsequent grounding of the whole 373 Max fleet cost Boeing a few billion dollars.

2023: Microsoft sold access to advanced logs in their MS-365 service as an add-on, premium product. Luckily, someone did buy it, and used the data provided to detect a significant intrusion in the whole Azure infrastructure.

For good or bad, we do not treat security as seriously as safety.

Yet.

I think this will change for critical infrastructure.

Microsoft should think hard what that would mean. If one can ground a fleet of planes for safety reasons, I see no fundamental reason not to temporarily shut down a cloud service until it can prove that it solved a design flaw.

We just need a regulatory authority with a bit more desire to be taken seriously.

Categories
CERT

A network of SOCs?

Crossposted on the CERT.at blog.

Preface

I wrote most of this text quickly in January 2021 when the European Commission asked me to apply my lessons learned from the CSIRTs Network to a potential European Network of SOCs. During 2022, the plans for SOC collaboration have been toned down a bit, the DIGITAL Europe funding scheme proposes multiple platforms where SOCs can work together. In 2023, the newly proposed “Cyber Solidarity Act” builds upon this and codifies the concept of a “national SOC” and “cross-border SOC platforms” into an EU regulation.

At the CSIRTs Network Meeting in Stockholm in June 2023 I gave a presentation on  the strenghts and flaws in the CSoA approach. A position paper / blog-post on that is in the works.

The original text (with minor edits) starts below.

Context

The NIS Directive established the CSIRTs Network (CNW) in 2016, and the EU Cybersecurity Strategy from 2020 tries to do something similar for SOCs (Security Operation Centres).

I was asked by DG-CNECT to provide some lessons identified from the CWN that might be applicable for the SOC Network (SNW).

The following points are not a fully fleshed out whitepaper, instead they are a number of propositions with short explanations.

The most important point is that one cannot just focus on the technical aspects of SOC collaboration. That is the easy part. We know which tools work. The same stack that we developed for the CSIRTs Network can almost 1:1 support SOC networks.

Our colleagues from CCN-CERT presented the Spanish SOC Network at various meetings recently. Yes, there was one slide with their MISP setup, but the main content was the administrative side and the incentive structure they built to encourage active participation by all members.

Human Element

Trust

Any close cooperation needs a basic level of trust between participants. The more sensitive the topic and the more damage could potentially be done by the misuse of information shared between the organisations, the more trust is needed for effective collaboration.

There must be an understanding that one can rely on others to keep secrets, and to actually communicate if something important for the partner is learned.

Trust is not binary

Trust is not a binary thing: There is more than “I trust” or “I don’t trust”; it always depends on the concrete case if you trust someone enough to cooperate in this instance.

Trust needs Time

Some basic level of trust is given to others based on their position (e.g., I trust the baker to sell me edible bread; I trust every police officer to do the basics correctly), but only repeated interactions with the same person/organisation increases the trust over time. (See “The Evolution of Cooperation”)

Thus, one needs to give all these networks time to establish themselves and the trust relationships.

These things really take time. We are talking about years.

Physical meetings (incl. social events) help

Bringing people together is very helpful to bootstrap cooperation.

You can’t legislate Trust

There are limited possibilities to declare ex cathedra that one has to trust someone. It might work do certain degree if people are forced by external events to collaborate (e.g., call the police if you have to deal with a significant crime; or reporting requirements to authorities; or hand your kids over to day-care/school/ …).

Even in these cases, these organisations have to be very careful about their reputation: misuse of their trust positions will significantly affect how much trust is given, even under duress.

Persons or Teams

Trust can be either anchored to persons or to organisations. I might trust a certain barber shop to get my haircut right, but I’ll prefer to go the same person if the cutter got it right the last time.

Experience has shown that is possible to establish institutional trust: If I know that Team X is competently run, then I will not hesitate to use the formal contact point of that team.

Still: if something is really sensitive, I will try to reach the buddy working for that other team with whom I have bonded over beer and common incidents.

Group Size

Close cooperation in groups cannot be sustained if the number of participants increases beyond a certain limit. This has been observed in multiple fora, amongst them FIRST, TF-CSIRT, and ops-t (which was actually an experiment in scaling trust groups).

As a rule of thumb: whenever you cannot have every member of the group present their current work/topics/ideas/issues during a meeting, then the willingness to have an open sharing decreases significantly. This puts the limit at about 15 to 20 participants. If lower levels of cooperation are acceptable, then group sizes can be larger.

Corollary: Group Splits

If a group becomes too big, then there is a chance that core members will split off and create a new, smaller forum for more intense collaboration.

This is similar to what happens with groups of animals: if one pack becomes too big to be viable, it will split up.

Adding members

Organic growth from within the group works best.

An external membership process (as in the CNW, where existing members have no say over the inclusion of a new team from another EU Member State) can be very detrimental to the trust inside the group.

Motivation

Cost

Any level of participation in a network of peers is not free of costs. Nobody in this business has spare time for anything. Even just passive participation via the odd telephone conference or even just reading emails costs time and is thus not free.

Active participation, be it travelling to conferences, working on common projects, manually forwarding information, or setting up Machine to Machine (M2M) communication can carry significant costs. These must not exceed the benefits from the participation in the network.

Corollary: Separate tooling is detrimental to sharing

Sharing information into a network must be as low-friction as possible. If an analyst has to re-enter information about an incident in a different interface to share the data, then the chance is high that it will not happen. Optimally, the sharing option is built into the core systems and the overhead of sharing is just selecting with whom.

Benefits

The flip side is often not so easy to quantify: what are the concrete benefits of collaboration? If the bean-counters ask to justify the cost, there should be clear business reasons why the costs are worth it. “Interesting discussions” and “being a good corporate citizen” is not a long-term sustainable motivation.

It must be as clear as possible what value each participant will get from such a network.

Beware of freeloaders and the “Tragedy of the Commons” effect.

Peers

Networks work best between organisations that are comparable in size, their jobs, and their position in the market. Their technology and informational needs should be roughly the same. They should face similar tasks and challenges. For example, the SOC of VW and the SOC of Renault should have roughly the same job and thus an exchange of experiences and data might be mutually beneficial.

Vendor/customer mix can kill networks

If two members of a network are actually in a vendor/customer relationship in terms of cyber security, then this is a strong detriment to collaboration. Even just a potential sale is tricky: if one member is describing his problem, then someone else should not be in the position to offer his own commercial product of service to address that problem.

I have seen this work only if the representative of the vendor can clearly differentiate between his role as network partner and his pre-sales job. This is the exception, not the rule.

Competition (1)

Ideally, the member of the network should be in no competition to one another. Example: the security team of Vienna’s city hospitals and the equivalent team of the Berlin Charité are a best case: their hosting organisations are working in the same sector, but there is absolutely no competition for customers between those two.

If the hosting organisations are actually competing with each other (see the VW vs. Renault example from above, or different banks), then a cooperation on IT security is not a given. Nevertheless, it is also not impossible, as competitors are often collaborating with respect to lobbying, standardization or interconnection. One positive example I have seen are the Austrian banks, who are cooperating about e-banking security based on the premise that the customers will not differentiate between “e-banking at Bank X is insecure” and “e-banking is insecure”.

Competition (2)

Even trickier is the case of SOCs not just protecting the infrastructure of their respective hosting organisation, but also offering their services on a commercial basis to any customer (“SOC outsourcing”). Anything one SOC shares with the network then potentially helps a direct competitor. Example: both Deloitte and Cap Gemini offer SOC outsourcing and Threat Intel reporting. Their knowledge base is their competitive advantage and why should they share this freely with a competitor when they are selling the same information to a customer?

Such constellations are extremely difficult, but not impossible to manage.

The trick to deal with competition in such networks is to move the collaboration to a purely operational / technical layer. These people are used to deal with their peers in a productive way.

Alignment of interest

This all boils down to

  • Is it a good commercial decision for my SOC to participate in the network?
  • Is it a good commercial decision to share data into the network?

Resources

All members must make the clear management decision to participate in such network and must allocate human power to it. In some way, such networks operate a bit like amateur sport clubs or open-source projects: they thrive based on the voluntary work done by their members. I have seen too many cases where such networks fail simply because members lost interest and did not invest time and effort in running them effectively.

Running a network

Secretariat

While not strictly necessary, a paid back-office increases the chances of success significantly. Someone has to organize meetings, write minutes, keeps tracks on memberships, produces reports, and provides an external point of contact.

Doing this on a voluntary basis might work for very small and static networks, where a round-robin chair role can succeed.

Connecting people

Bringing people together is the basis foundation of a collaboration network. Only in the case where the network is only the distribution of information from a handful of central sources to all members (i.e., a one-way information flow), then this might not be needed. This can be done by (in order of importance)

  • Physical meetings (conferences, workshops, …)
  • Continuous low-friction instant messaging
  • Mailing-lists
  • Web-Forums

Generic central tooling

Any network, regardless of topic, needs a few central tooling components:

  • A directory of members (preferably with self-service editing)
  • A file repository
  • An administrative mailing-list
  • A topical mailing-list
  • An instant messaging facility

A decent Identity and Access management covering all these tools is recommended (but not strictly necessary in the first iteration). The toolset created for the CSIRTs Network (MeliCERTes 2) can help here.

Exchange of Information

In the end, the main motivation of such network is information sharing with the intention of making members more effective in their core task. Here are some thoughts on that aspect:

Compatible levels of Maturity

If members are at very different levels of technological and organisational maturity, then any information exchange is of limited value. A common baseline is helpful.

Human to Human

This is the easiest information exchange to get going, and some topics really need to be covered on the human layer: people can talk about experiences, about cases, about what works and what does not.

It is also possible to exchange Cyber Threat Intelligence (CTI) between humans: the typical write-up of a detected APT campaign, including all the Indicators (IoCs) found during the incident response, is exactly that.

This sounds easy, but is costly in terms of human time. On the receiving side, the SOC needs to operationalize the information contained to make the automated systems detect a similar campaign in the local constituency.

Information Management

The way a SOC is gathering, storing, correlating and de-duplicating the CTI that is powering its detection capability is a core element in the SOC internal workflow. Its maturity in this respect drives the possibilities of collaboration on the topic of CTI.

One (not uncontroversial) theory on this topic is the “Pyramid of Pain” concept from David Bianco, where he describes the levels of abstractions in CTI. The lower levels are easy for SIEMs to detect, but also trivial for the threat actor to change. The challenge for SOCs is to operate at a higher level than what the threat actors is prepared to change frequently.

CTI M2M

In theory, SOCs should be able to cross-connect their CTI systems to profit from each other’s learnings and thus increase the overall detection capability of SOC Network. Regrettably, this is non-trivial on multiple fronts:

Data protection / customer privacy

They must be ensure that no information about the customer where the CTI was found during IR, leaks out. Sometimes this is easy and trivial sometimes it is not. Thus, unless the SOC is very mature at entering CTI into their system, people will want to check manually what is being shared.

Data licencing

Many SOCs buy CTI data from commercial sources. Such data needs to be excluded from automatic data sharing.

Data compatibility

While there are a number of standards for CTI data exchange (e.g., STIXX/TAXII, MISP or Sigma rules), this is far from being a settled topic. Especially if you want to move up in the pyramid of pain.

Sharing tools

In addition to sharing information, it is also possible that members of the network share the tools they have written to perform various aspects of a SOCs job.

Categories
CERT Internet Pet Peeves

Of Ads and Signatures

Both advertisements and signatures have been with us in the analogue realm for ages, the society has learned about their usefulness and limits. We have learned that it’s (usually) hard to judge the impact of a single ad, and that the process of actually validating a contested signature is not trivial. There is a good reason why the law requires more than a single signature to authorize the transfer of real estate.

Both concepts have been translated to the digital, online world.

And in both cases, there were promises that the new, digital and online versions of ads/signatures can deliver features that their old, analogue counterparts could not do.

For ads, it was the promise of real-time tracking of their effectiveness. You could do “clickthrough rates” measuring how often the ad was clicked by a viewer. The holy grail of ad effectivity tracking is the fabled “conversion rate”: you can measure how many people actually bought your product after clicking an ad.

For signatures, it was the promise of automated validation. If you get a digitally signed document, you should be able to actually verify (and can have 100% trust in the result) whether it was really signed by the signatory. Remember: in the analogue world, almost nobody actually does this. The lay person can detect crude forgeries, but even that only if the recipient has access to samples of authentic signatures. In reality, a closer inspection of handwritten signatures is only done for important transactions, or in the case of a dispute.

So how did things work out after a few years of experience with digital ads and signatures?

Digital ads are in a midlife crisis. We’re in a death spiral of low clickthrough rates, more obnoxious formats, ad-blockers and ad-blocker-blockers. Just look at the emergence of Taboola and similar click-bait.
Digital signatures are at a cross-road as well: The take-up rates of solutions based on smart-card readers have been underwhelming so far. This applies to the German ePerso as well as to the Austrian citizen card. The usability just isn’t there. So there has been a push to increase the take-up rate by introducing alternatives to smart-card technology. That won’t make it more secure. Not at all.

So what’s the common lesson? In theory, both digital ads and signatures can offer features that their old, analogue counterparts just cannot deliver. In practice, they are killing themselves by over-promising. As long as click-through rates are the prime measurement of online ads, their death spiral will continue. And as long as digital signatures continue to promise instant, high-confidence validation, they will not achieve the take-up rates needed for broad acceptance.

Continuing the current trajectory will lead to a hard crash for both technologies. On one side it’s the ad-blocker, on the other side it’s malware.

The level of spam in the email ecosystem meant that no mail-service can exist in the market without a built-in spam-filtering solution. And given the early ad-excesses every browser includes a pop-up blocker these days. If the advertisers continue on their path of getting attention at all costs, ad-blocking will become a must-have feature in all browsers, and not just an optional ad-on (as right now).

Any digital security solution that protects actual money has been under vigorous attack. The cat and mouse game between online-banking defenders and attackers is a good lesson. The same will happen if digital signature solutions start to be actually relevant. And good luck if your “let’s make digital signatures more user-friendly” approach is actually less secure than what online-banking is using these days.

So what’s the solution?

In my opinion the right way to approach both topics is to reduce the promise. Make digital ads static images. No animation. No dynamic loading of js-code (which is its own security nightmare). Don’t overtax the visitor’s resources (bandwidth, browser-performance). No tracking. Tone it down. Don’t expect instant effects. Don’t promise clicktrough rate.

For digital signatures: Mass deployment is only possible for “non-qualified signatures”. Don’t promise “you can fully and solely rely on our solution”. Just sell “this is a good indication”, or “use this as one factor in your security design”. Prepare for it to be attacked and broken. Only use it when you have a pre-planned way to recover from such a breach. The real word is full of applications where signatures are used in a very low-security / low-impact settings. The state-sponsored digital identity solutions needs to think of those, too. For the high-impact, high-confidence settings I always have to think about the mantra we use at work: “You can’t mandate trust.”

Categories
CERT Pet Peeves

The Edge browser

Wasn’t one of the main goals of junking the Internet Explorer codebase and building a brand new browser “Edge” the hope that there won’t be the monthly batch of patches for remote code execution vulnerabilities?

I haven’t tabulated the advisories but somehow I don’t have the feeling that things have gotten substantially better.

Why?

It looks to me like we still aren’t using the right programming environments for such complex pieces of software. There is still way too much basic security tooling the programmers have to do by themselves. Just like you shouldn’t do string operations in pure ANSI C, we need to rise the level of abstractions that all these browser bugs (that lead to RCE) just are not possible any more.

Categories
CERT Internet Pet Peeves

Adobe Flash Updates

Today we’ve seen yet another Adobe Flash Player update due to serious problems. So be it.

One thing always sets my teeth on edge when doing/verifying it: The number of clicks it takes me to check the version of the currently running Flash plugin. It would be far too simple if the download page (which is prominently linked everywhere) would just tell me if I need to upgrade. No, I have to click on “Learn more about Flash Player”, then “Product Page”, then “FAQ”, then scroll down to “How can I tell if I have the latest version of Flash Player installed and whether it is working correctly?”, click to reveal the answer, then click “Testing page”.

And then I have to manually compare the version shown above with the latest version listed by operating system and browser beneath.

What the fscking hell is Adobe thinking? They’ve been a top reason for PC infections for the last years (Flash + Acrobat) and still they don’t tell their web-visitors as quickly and efficiently whether they need to update.

Can someone please administer the necessary clues with a suitable LART?

Categories
CERT Internet

The Evolution of Conference Wireless

  • 2003: RIPE offers to rent out PCMCIA wifi cards to attendees of the RIPE conference.
  • 2007: Every attendee has a laptop with built-in wifi.
  • 2012: Every attendant brings a Laptop and at least one smartphone, some bring tablets as well.

We have ~500 attendees at #FIRSTCON this week; I wonder how many distinct clients the wifi net has seen.

Categories
CERT Internet

DNSSEC Troubles

I’ve given my share of DNSSEC talks over the last three years. I usually explain what exactly DNSSEC provides and what it does not. One of the downsides I tell ISPs about is that other people’s DNSSEC errors will hit your call-center if you’re doing DNSSEC-validation.

This just happened to Comcast.

I really recommend that anyone enabling DNSSEC validation on their resolvers should be prepared for this case. The report from Comcast is instructive, especially the media fallout they had to cope with.

Categories
CERT

The WOW-Effect

This week I had some fun helping a co-working with a paper regarding the effect of WOW64 (the 32-bit environment of 64-bit Windows) on various tools and procedures that security analysts use.

The result is here: The WOW-Effect.

Categories
CERT Internet

#DigiNotar and paying for an audit

The question Mozilla, Microsoft and Apple should be asking themselves now is:

Which other CA do they trust based on an audit by PwC? Their green light on DigiNotar was so flawed that I have serious doubts about anyone else they certified as a trustworthy CA.

This is a bit like the financial rating agencies at the height of the 2008 banking crisis: why the hell should I trust the audit/rating of someone who is paid by the people they are auditing/rating and who need an “all fine”/AAA result?