Why is security hard? (or maybe, If it Bleeds, it Leads?)

It appears Equifax has had its fifteen minutes of fame. It came and went as fast as the the winds shifted in Washington and another shiny story caught the eye of the press. But it made me think...

Anyone else remember Fred Giesler? Fred was a cool old guy that taught the information warfare program at the National Defense University at Ft. McNair. 

Fred ran a class on full spectrum information operations, and one of my favorite speakers was a CNN reporter that operated his own refurbished C-130 gunship, in which he operated cameras instead of guns in the side doors… and the quote I'll remember forever from this guy, and Fred, was "if it bleeds it leads". 

And so it comes to Equifax. I saw this headline in an online security publication that I used to read often —today not as much, but this brought back a vidid memory of my days in information warfare training ..."if it bleeds it leads". I'm not sure who took advantage of who, but...

"Lawmaker rips Equifax for eschewing DHS's Automated Indicator Sharing program"

"Rep. John Ratcliffe, R-Texas, chairman of the House Cybersecurity and Infrastructure Protection Subcommittee, slammed Equifax, still reeling from a breach that affected 143 million Americans, for not taking advantage of the Department of Homeland Security's Automated Indicator Sharing program, designed to facilitate the sharing of threat indicators between government and the private sector."

According to a 2015 US Census Bureau report, 99% of the companies in the US are less than 500 employees. If that's the case, 1% (or less) of the security folks in the US know what it feels like to manage security operations (i.e. patching) in companies larger than 500 —right? And even a smaller, much smaller percentage operate in larger enterprise companies —of which Equifax is one with roughly 10,000 employees. 

I'd like to take a moment and offer a small education for Rep. Ratcliffe:

There is a ton of noise out there. You can't swing a dead cat without someone selling, pushing, or dumping indicators of compromise on you, and the DHS AIS program, while probably good enough for most, is, I would argue, likely not as good as the intelligence processed by the Equifax team today. In fact, I've had conversations with them in the past. I'm jealous of their malware processing capabilities. Even if Equifax had participated in DHS's AIS program, they would have had to sift through the noise to get to the good stuff… and my bet is, they probably had it already.

Assuming DHS had given them information on Struts (I'm certain they probably included it in their subscription, and I did see it in Infragard reporting), patching in large distributed enterprise environments is to say the least, difficult. Why?

• Almost no company has full visibility into every computer on their network. Why? As companies grow, either through acquisition or organically, tools change, people change, and requirements for IT change —usability, storage, operational requirements, etc. Security must change too. Unfortunately, one can simply not reengineer the entire security posture with every change. Virtualization and cloud processing brought massive requirement changes for security but, even if the tools existed to manage all of these new advances in IT, budgets did not, and could not keep up. 
• Assuming they had both full visibility and ability to reach every computer, in global companies, it still takes time to push. And since we know assuming makes and "ass of u and me", it's a safer bet that they probably didn't have full visibility. Full viz is nearly impossible.. In fact, I'd say it probably is.
• There's a real shortage of skilled labor - Actually, maybe not a shortage of labor but a shortage of skilled labor —with all of those cloud, virtualization, and deep technical capabilities needed to operate in todays environment, there are no more one-size-fits-all security folks.
• The Fog of War - Let's do some simple math. Equifax has ~10,000 employees. On any given day there will be 3-5% moves, adds, and changes. That equates to roughy 400 computers in motion every day. Add in those compromised, plus mobiles, plus tracking those in motion, and then dealing with the multitudes of alerts from the many technologies used to defend them. The numbers are staggering. This is absolutely nuts. Now let's go back to number one… almost no company (I'd argue large, or small) has full visibility and control into every computer on their network. I say again -staggering. The Fog of War changes everything —how you see the problems(s), which one(s) you handle first, and figuring out best how to use the limited resources that you do have.
• Inadequacy of tools - Nearly every tool is Windows based. Unix, Linux, Solaris, BSD all require higher degrees of manual processing. While not impossible, accounting for patches, updates, system outages, and even simple inventories require higher levels of due diligence and manual processing.

I could do this all day. There are no less than 300 reasons that could have cost a simple miss —one that on that particular day, at that particular moment, something went wrong, leaving a hole exposed.

I do not fault Equifax.  I've said this many times in past blogs. I know exactly what it feels like to be a security operator in a large enterprise company. And, I know exactly what it feels like to be a security operator in a very small company. This is a hard business and I'd throw the bull sh*t flag at anyone who tells me that they have perfect security and could have prevented this. I'd throw the bigger bull sh*t flag at the person who says that by being a member of DHS's AIS program, the Equifax breach could have been stopped. Heck, my own marketing people urged me to write a blog that said that we'd seen information that would have stopped the breach. I could not, and would not. Others? Maybe. Not me. The Internet was not built to be secure, and adding layers upon layers upon layers of tools and technologies on top of this insecure foundation will eventually cause a massive failure. The fact that we trust it with nearly everything is a fools game.

I rarely pay attention to the security news anymore. There are a few to whom I will talk, but even then, I watch with one squinty eye to see if I'll be misquoted —and if I am, I don't talk to them again. The magazine that quoted Ratcliffe? I stopped reading them in 2002 when I was a new Cisco employee and they misquoted me; I took a real blistering from my co-workers for that one.  For some reason, every now and again, one of their stories pop up on my radar. I generally pass it by but this one? For whatever reason, I couldn't let it pass. I was compelled to write about it. 

In the mean time, nearly every time I see one of these headlines, my butt clinches and I smile. I think of Fred Giesler… if it bleeds it leads.

For Rep. Ratcliffe? Send me your computer. I'll bet a dollar it's not up on its patches :)

I have to laugh. 

An mambo dogface in the banana patch?

Steve Martin had this routine where he talked about playing a cruel joke on kids —by teaching them to talk wrong.  As a kid, I laughed many times, listing to this old record over and over, but last week, something happened that made me laugh --not because it was as funny as Steve Martin, but because I listened in horror as a well paid security guy sprinkled in words and phrases that he absolutely nothing about.  

When I was an Ensign (ok, and sometimes as a JG) we used to (sometimes) sit in meetings and write down all of the acronyms, buzz words and power phrases, and then string them together to make jibberish paragraphs that actually sounded like they could be legit! It was even more fun to hear those phrases later when someone else picked them up and used them as their own. Imagine how hard we laughed!

A few years ago I had a young guy that worked for me in, who after a few drinks at an offsite used the phrase "fake it till you make it".  I hadn't thought about that comment in a while but I was reminded of it last week during a conversation with a young security pro(?), who I'm convinced writes key words and buzz phrases from the multitude of information security conversations he participates in and then saves them in reserve for those times when he's in a conversation where he needs be credible, but lacks depth. The thought is, sprinkle in a few important words, names or concepts —regardless of how well they're known, do it with conviction, take cover from the halo effect of previous successes, and there's a high likelihood that won't be (most times) challenged.

I feel like I'm seeing this more and more. I went to an ISC2 meeting where a Mandiant exec (at the time) and I both presented on APT. We talked about indicators and TTPs, until one brave young woman, in this otherwise deer-in-the-headlights audience, chimed in and asked What is an IOC? OK, so she's the CISO for a string of medical facilities and should know that, but if there were ever a place to ask the question and get an education, it'd be at an ISC2 meeting right?

Good for her! 

Last week one of my own guys, when talking about possibly introducing a new application, made a comment (something to the effect) Changing a firewall rule is easy! Anyone can do it! To which I responded When's the last time you changed a firewall rule? And, when's the last time you changed that firewall in a large enterprise company (like our customers)??

This is hard stuff. You can't just log into a Netgear box and increase to the next highest security settings needed to keep you safe. There are a dozen (or more —usually more) interdependencies that also must be considered.

In fact, this is one of my favorite (past) presentations, I talk about the SANS Top 20 controls, ISO 27001, and NIST. The could easily go for an hour, but it's only one slide long. I talk about the moats and controls that must be built around critical assets, and I talk about the fact that there are like 300 things that must be done right every minute of every day, and if you miss even one, well…  At that time, I was talking about large enterprise. Today, however, after having been in the seat for just under six years, I'm finding that even the smallest companies have those exact same problems. 

So I'm thinking maybe it's time to blow the dust off of my one slide 'Why is Infosec Hard?' presentation and do some training on change management in defense in depth, system design requirements, network design requirements, and the butterfly effect that happens when making internal defensive changes. It's a hard lesson but important. 

I don't fault anyone for the lack of depth. The just one of those things where if you've not operated in a SOC, you may not know how hard it really can be. As well, we've gone from 10 mph in demand to over 100 mph in the last few years —virtualized footprints, the criminal shift from having fun to making real money, regulatory requirements, government reporting, and a dozen other variables have all contributed to this massive sucking sound —sucking many many people into positions to which they may not yet be ready.

So where do these people go for help? Besides asking friends (who are, many times, in the same boat as they are), they come to information sharing environments. In some, they get a steady stream of IOCS, in others, they get hammered by vendors paying their way into educational speaking engagements, and in others they get two way collaboration in which they can ask those question, receive non-biased information. 

One of the reasons that I absolutely LOVE the idea of information sharing is because there are no stupid questions! And if you feel like you're going to be embarrassed asking the question in one of our public forums, IM or DM us and we'll answer you in private! Heck, request a training session. We do one every Friday! Maybe someone else will benefit too. 

Red Sky Alliance isn't here to sell you products or services. Its only purpose is to share information collaboratively. And its changing to stay up with the times. We run this area that we call the Cyber Threat Analysis Center (CTAC for short). I like to call it ISAC 3.0 but it's really a suite of our favorite tools in one desktop made available for our customers.  Open the desktop. Select a tool. Need a script? Open our Script repository and either grab one you need or collaborate on building one. Need help? We're here. Open HipChat or Slack and ask for help. Need a report? Fast? We have an archive. Need something fresh? Try Wapack Pagekicker. Enter your query, wait thirty seconds and get a machine written report. 

Let's leave "An mambo dogface in the banana patch" and get everyone on the same page, speaking the same language, educating each other. Yes, we can do this. 

Call me for a demo. Yes, I take phone calls too.

NEW! and Ridiculously Simple! Wapack Labs RiskWatch

Ridiculously simple is going to be my mantra. Wapack Lab's RiskWatch makes monitoring threat Ridiculously Simple. Define Ridiculously Simple you say?

We can do it for you, or you can do it yourself.

For the individual: Sign in, enter an email. That domain gets checked and monitored. When we see something, you get a report. Simple right?

RiskWatch tally's the number of times any of domains, IP, or domains are seen in our intelligence. If it is, a report is generated and you get an email.

When the recipient of one of our emails logs in (for free), they'll see a dashboard that will give them enough information to fix the problem. For a small fee (starting at $9 per month) the victim can sign up for a detailed look, including raw logs and a notification service.

Think credit monitoring, but we're watching for malicious activity targeting you.

For your company: Today, our analysts screen thousands of companies. When we find issues, we'll enter a point of contact and you'll get the report. Fix away. Interested in having one of these in your own company? Use it for reporting security concerns, risks, threats to your suppliers? Partners? Easy.  Interested? Drop us a note. We're working on that console as we speak.  We'll call you when we're ready.

I was told "think Equifax report".

As of this morning, we've sent out over 1300 suspicious activity reports to individual users in the last two days.  Received one? No sweat.  Sign in. We'll build your report on the fly.

Want to be proactive? Sign up on the site. If we see something, we'll tell you!

Simple right?

RiskWatch is Patent Pending.

risk.wapacklabs.com

Could we have stopped the Equifax breach? Leading Indicators?

I have this friend (it seems like all the best stories start this way —or with This is a no sh*tter!). Regardless.. I have this friend. He's a long time friend that I worked with years ago during the days when I spent my morse code shifts with the positions glass door closed, head sets on to drown out external  noise, studying calculus while I waited for the next AMVER, or worse yet …- - -…  …- - -…  …- - -…

After leaving the Coast Guard, he went on to become a sales giant with Big Blue, and of course you know where I ended up!

This old friend, we'll call him Mike (I call everyone Mike when I want to anonymize them) was working us through a 'so what' exercise on Thursday night when the phone rang at about 6:00 —it was WMUR, the local ABC Affiliate, who wanted to come to the lab and interview us for comments on the Equifax breach. At that point I hadn't really kept up. Equifax is bad, but so are all of the others —OPM for example (of which most of my team were included). Equifax was just one more breach from a company who likely let their guard down for a moment, and ended up getting screwed as a result.

In preparing for the interview, I quickly pulled up our internal Kibana instance (you've heard me talk about Cyber Threat Analysis Center? An ELK stack is one of the tools that we make available to our members. So.. I pulled up our internal Kibana and punched in the search term *equifax* with a one year time window —and whadya know…

At the time, we knew that Equifax claimed to have identified the breach in late July. We suspected they'd actually suffered the breach earlier; it's rare to catch the breach on Day 0. I wouldn't surprise me to hear that this incredibly talented security team at Equifax probably caught it much earlier. I've met and had beers with these guys. The are scary smart like I was at that age ;) , and my bet is, they followed the same smart process that any large company would follow before reporting out… they identify the breach, investigate the breach, and at the same time, fix the hole and assess just how bad it is. They then break out the mop. The legal team decides how far it extends and what the reporting requirements are, and then, if they choose, the PR engine fires up. This entire effort could take anywhere from days to months. My estimate would have been that they would have actually suffered the breach approximately two to three months before they announced —sometime between late April and late May. Apparently I was close. Scuttlebutt says May.

So why the chart? We monitor all kinds of proprietary intelligence sources that give us leading indicators of when we think something might be coming. We had early warning on Amazon when Jeff Bezos was portrayed as the Devil Boss in the press a few years ago. We had increased levels of cyber activity (although we had no idea what it meant at the time) before the Paris shootings, and we had a leading edge spike in cyber indicators leading into the time when Equifax was believed breached. Of course this is all speculation at this time, but… what did we see?

• A trojan was sent, several times, to three people —a senior account manager in Mexico, the Information Security Officer in Costa Rica, and an email account that appears to be associated with an unemployment claims service.

We identified these indicators —none of which were delivered —but we see only a small sample. My suspicion is that we saw only the unsuccessful indicators, but in many cases, there are several others occurring at the same time; we just don't have eyes on those sources.  The indicators that we identified were associated with emails sent to these users, with a trojan attached, delivering ransomware that sometimes (not always) uses a C2. 

There were other indicators from open source and misc others, but they didn't appear, at least on the surface to hold any kind of meaning. 

From an analytic perspective: 

• FACT - We saw activity on the leading edge of the currently believed timeline of the incident. 
• FACT - That activity targeted three locations (people and email accounts) that would have had significant access:
• The Senior Account Manager would have had access to Equifax's customer relationship management (CRM) systems —that database that contains all of the customers information, easily access by sales and marketing teams to allow tracking of sales efforts.
• The Information Security Officer, if breached would probably have administrative rights on some systems but not all. He would have knowledge of detailed local business unit operations, systems and locations of sensitive data.
• The targeted email that we identified in our collections was associated with unemployment claims -and one (one that we saw), appeared to be sent from an Equifax user to a hospital —apparently looking for health information to support some kind of claim argument. 
• ANALYTIC GAP - Did Equifax receive other emails like the ones that we saw, but with successful delivery?
• ANALYTIC GAP - Why the spike in activity on that day anyway? Why was that day so special, as to have received almost three times as much activity as any other day in the preceding twelve months, and to date following? 

SPECULATION

• We saw only part of the storm.. the derivative of the storm. I believe that we may have seen activity generated by automated sensors, but it may have been only a small piece of what was actually happening. 
• My bet is, others were targeted at the same time. In this case, we was emails with, at the time, a virus total detection rate of 2 out of 57 attempts, and others were probably compromised.
• Some of what we saw were attempts to deliver ransomware —a diversion? Noise?

I'd make a low confidence assessment that goes something like this… I'm going out on a limb here. This is a first SWAG (Scientific Wild Ass Guess) at what may have occurred. Equifax is neither a customer or are we under NDA with them, so lets have a little fun. This is a total SWAG.

• Access occurred in Latin America (Central America if our indicators are true).
• The ISO was targeted to help him from working
• The Salesperson was targeted because sales people have access, and are easy targets.
• The unemployment line? No idea. Maybe because it was on the list?? 

Of course, that assessment will change over time as more information becomes available and as our sensor systems collect more information. Let's see how close I come to the real story. I'm betting we'll hear it in the future. It's to big to be swept under the Trump carpet (the noise that happens when he tweets in the middle of the night). 

So, for my sales buddy? He wanted to know… Could Wapack Labs have stopped this attack? 

Probably not. Could we have given them warning that might put them on higher alert, positioning them to stop an attack? Absolutely, yes. We would have put them on alert —for good cause.

For many customers (albeit, not Equifax), we deliver as-it-happens and weekly reports that show these pieces of information as we know them. Equifax most certainly may have benefited from our identification of a 3x spike in cyber activity targeting them on that that particular day. At a minimum, the security team would have been issued a warning, and would probably have taken a more heavily monitored perspective. I told you, that team is scary smart. I'm certain they would not have let our warning pass.

This is where humans have value. Machines are cool. AI is cool. But this set of indicators needed to be interpreted by a human (me), who can read between the lines and think in the gray areas. Humans have value, and information sharing has value. This analysis is posted in Red Sky Alliance, and this is where information sharing has value. We'll let our membership to evaluate our data with their own eyes and participate in the discussion 

For others? Drop me a note. We'll sign you up.

Traveling today. 

Have a great weekend!

Jeff

There ya go again Stutzman. You're selling the steak!

On Thursday, an old friend from my enlisted Coast Guard days stopped in for a visit. We'd left the Guard at about the same time; he went to work for IBM and stayed there for 21 years to become an expert salesman. I went to Navy OCS and became an intelligence officer and a professional analyst.

For the first half hour in my office, we walked through our offerings. I could see in his expressions that he was thinking critically about what I was telling him. All the while, he kept asking me "So what"? "So what?" "So what?" This is the same thing that I do to my analysts when they present me with an idea for a paper.. I "so what?" them until we can't "so what?" any more to get to the root of why anyone would want to read that piece of analysis. In this case, the tables were turned on me. He kept saying "you have to make it simple". You're selling the steak when you really need to explain, and make them sense, the feeling of sitting in the restaurant, and the first cut into that perfectly done filet. He told me that ours was some of the best intelligence he'd seen in the space, but our messaging was complicated and didn't represent our product line as well as it should. 

Yesterday I received an email today from a company (a $3 billion per year company). We'd been demo'ing our firehose of intelligence.  He explained that they created their Infosec team small by design. They told me that they have an MSSP that handles their firewalls, and outsource other parts of their world to keep their internal team lean and mean. They'd considered our services but felt it was overkill for what they need. 

We sell lots of things, but they all boil down to two primary lines —you can do it yourself (DIY) using our tools, or we can do it for you.  In either case, you get access to Red Sky Alliance where you can share information, ask questions, and compare notes.

The DIY approach consists of accounts in our Cyber Threat Analysis Center (CTAC for short) —a place where we've loaded up a SaaS environment with suite of amazing analytic tools ranging from Elastic to CyberChef and H20. We've got Zeppelin, and GitBook/GitHub for sharing code and documentation. On the backend we've loaded our intelligence, pre-built some queries, and essentially, built an expert level sandbox for highly skilled analysts who love twisting and turning data. DIYers LOVE this offering —it puts everything they need at their fingertips. In fact, I joke and tell people that I'm following Bloomberg's business model! We supply the data, tools, and training. You supply the brain cells. 

At the other end of the offering, we've had several companies who tell us "we don't want to invest in intelligence", or, "we've already spent enough money on infrastructure", or, "we've intentionally kept our team small".  In those cases, we become their intelligence and analysis team, supplying inputs into their Information Security, Fraud, Physical, Risk and Intellectual Property teams.

So Jeff (my Coastie turned IBM friend) looked at me and and asked "How much would it cost if you sent me a weekly report, specifically for me and my company?

I gave him a price. That's easy I said. We do it all the time.

Back to my $3 billion per year prospect —They also told me that they couldn't handle intelligence inputs into their security team —they leave that to their MSSP and a small team. The head guy didn't want to invest in the DIY program. But, on more than one occasion we'd given them both compromises in their supply chain, and internal networks —things their MSSP should have seen, but missed. And when we did, in every case (three times), the analyst that we presented with our findings, acknowledged them in a positive way, once publicly.

I'd made a fundamental error.

I'd been trying to sell them on DIY, when whey they really wanted and needed, was option 2.

We're hearing this more and more… There's to much intelligence. We don't have a good way to process it. We're not interested in building an intelligence team. We rely on our MSSP for that. Or maybe it's what my old pal Jerome calls the 'green light syndrome' (where security people watch for the green light, and if it's green, they're good).  Not everyone wants to grill their own steak. Maybe they just want to pay a little more to sit at a nice restaurant and have a perfectly cooked filet mignon be placed in front of them. 

Wapack Labs is working hard to make this ridiculously simple. In the next few weeks, we'll be launching a tool to drip out the most important stuff -in chewable byte sized chunks. We've assigned primary analysts to each of our customers as their go-to analyst. And we've begun sending out reports and ad-hoc warnings. If you still want to be a DIY'er, please! By all means! But if you're one of those "we need it simple" types of folks, you're going to love this.

Interested in having a look? Check out wapacklabs.com, or sign up here for more information.

BT

For those affected in Texas, we're thinking of you. As of this morning when I last watched the news, 39 dead, not to mention untold numbers of folks displaced or stranded. We're thinking of, and praying for you.

Until next week.
Jeff

What's the thinking on the USS John F McCain? Directed Energy?

During the Presidential primaries, we authored an intelligence assessment regarding the North Korean potential for an Electro Magnetic Pulse (EMP) floated over a city in the US and detonated, leaving electronics for miles on their death beds. Last week we published a piece on GPS Spoofing in the Black Sea, showing three ships nearly 25 miles away from where GPS put them —in an inland Russian airport. And tonight I'm seeing a number of youtube videos talking about directed energy weapons (DEW) having been used (speculation of course) against the John F. McCain. The video shown below is one of many, now speculating on the idea that a DEW may have been used against the JFMc.

Regardless of your thinking on this (I happen to believe that human error could not have caused this crash), the idea that an EMP or DEW may have been employed in this incident should not be that far fetched.

You see, (ahem) years ago, we had this thing called TEMPEST. TEMPEST was essentially the hardening of computing gear by wrapping it in grounded shielding, sealing seams with braided wire, and ensuring that all of our communications gear was protected from both eavesdropping, and external interference. Just hours before the McCain collision, we reported on GPS spoofing by someone in Russia against three ships in the Black Sea, showing their position nearly 25 miles off, and inland at an airport. This report of course caused my phone to explode. Reporters everywhere wanted to know if I thought this could have been the cause of the collisions in both the Fitzgerald and McCain. I have no idea, but, it's not out of the realm of possibility that someone from shore could have offered a stronger GPS signal that that of the birds, thereby causing the onboard systems —either on the warships or on the commercial vessels, to associate with it, rather than the satellites.. much like your laptop associating with a stronger wireless access point when you're sitting in a coffee shop. And after linking with shipboard receivers with a false signal, showing the ships on very different courses than originally thought. 

I'm not saying it happened, but it isn't crazy either.  A DEW —directed energy attack, is similar except the attacker doesn't care about about modifying GPS, their goal is to scramble or block electrons, leaving scopes unreliable.

So, is this a cyber attack? What's the thinking? We think it is, but not from the network. In this case, assuming a DEW was employed, it could easily overwhelm non-TEMPEST bridge instruments… I'm not much into speculation, but damn. 

Why do we care? 

First, we lost lives on two ships.  Second, About 20 years ago I gave a talk at a SANS conference where I retold a story that had appeared in a WSJ article. It goes like this… a nondescript van drives through the financial district in NYC, and as it passes, computers monitors flicker and die and electronics mysteriously fall off line. I told the story, coupled with (slightly fictionalized) accounts of incidents I'd worked, both as one of the first Internet Storm Center (then called the GIAC) watch standers, and from my work in the Navy.  I was given poor reviews, with one calling me out as a snake oil salesman. Until a few years ago, I gave that exact talk at the Navy War College for Admiral Hogg's Strategic Studies group. 

DEW and EMP are a threat to cyber, and the world knows how much we rely on it.

If your cyber threat intelligence shop isn't considering the likelihood and impact these external threats, and if you're not thinking about how you might deal with a catastrophic electronic event caused by more than just skids, hactivists, or APT, without thinking risk and resilience for a larger scale attack, you might be missing something in your enterprise risk management plan.

If you'd like to read our assessments, call me or join our Read Board community.

For now, I'm off. 

Have a great weekend.

Jeff

An analysis of China's Military Cyber Force: PLA Third Department and its Technical Reconnaissance Bureaus

We recently published a detailed, but unclassified paper entitled "China's Military Cyber Force: PLA Third Department and its Technical Reconnaissance Bureaus". The paper is being provided at no charge. 

EXECUTIVE SUMMARY

Several elements of China’s People’s Liberation Army (PLA) General Staff Third Department have been identified by Western analysts as involved in cyber intrusions into U.S. and other foreign networks.  These include the Second and Twelfth Bureaus of the Third Department, also known as the 61398 Unit and 61486 Unit, respectively, which have been profiled by Mandiant and CrowdStrike.  The Third Department’s Technical Reconnaissance Bureaus (TRB’s) are also suspected of involvement in cyber operations.  The Chengdu Second TRB (78020 Unit) was identified by ThreatConnect/DGI in 2015 as also conducting intrusions.

Based on this information, Wapack Labs conducted research on other Third Department elements to determine their possible involvement in these cyber operations mission for China.  Third Department units were profiled based on their published academic work, which revealed a subset of elements whose research was predominantly of cyber issues rather than SIGINT-related topics.  The elements identified were:

• Third Department Computer Center (61539 Unit) in Beijing.  This center has a network security research mission and publishes extensively on computer security issues.
• Chengdu Military Region Second TRB (78020 Unit) in Kunming.  Identified as a cyber actor, its academic work focused almost exclusively on computer security issues.
• Lanzhou Military Region First TRB (68002 Unit) in Lanzhou.  There were 20 personnel at this unit identified as authors on cyber topics.
• Lanzhou Military Region Second TRB (69010 Unit) in Urumqi.  Facilities for possible cyber operations have been built at a base separate from SIGINT operations.
• Chengdu Military Region First TRB (78006 Unit) in Chengdu.  Addresses for authors of computer articles correspond to a Headquarters base separate from SIGINT operations.

     The paper may be downloaded here. "China's Military Cyber Force: PLA Third Department and its Technical Reconnaissance Bureaus"

    As a precaution, I've implemented a 24 hour delay between sign-up and paper delivery to allow verification of the request and user. 

Ridiculously Simple - Wapack Labs CTAC fully integrated with ThreatQ

I haven't blogged as much as I normally do this summer. The kids are getting older and vacations and… well… at any rate, it doesn't mean work stops, nor does it mean that we stop pushing to make it ridiculously simple for users at any level access intelligence needed in their SOC, in their risk programs, or as we're starting to find, even the physical security guys are reading our stuff.

Last year we worked hard to get data into a foundational tool that could be used to serve our data up to any number of different applications. Unfortunately for a number of reasons, we didn't get it done, but late last year after a few organizational shifts we went live in a VERY alpha state in January, followed by an MVP launch in March, and now, I'm happy to say, we're seeing new products and applications come alive, bolting on themselves to us.

Our 2013's Threat Recon(R) was our first real push into serving up data (IOCs) through an API.  It remains a popular, Wapack Labs low cost API. Today in 2017,  I'm happy to say, our Cyber Threat Analysis Center (CTAC for short) is online and rolling nicely. Now, users can access more than just our Threat Recon(R) data. They can also search, manipulate and download nearly every collection acquired by the team. CTAC serves up not only Threat Recon(R) data, but also key logger outputs and sinkholes; 'bin' scrapes, early warning, and more.

As a result? Greater interest in accessing and integrating our data into their analytics and tools. One that we were really happy to see was ThreatQ.

Why do I say 'ridiculously simple'? ThreatQ has completely integrated our stuff to the point where an analyst only has to point at our reporting, ingest it into ThreatQ, and after a very simple process of letting the machine do its thing, the data is parsed, correlated against other ThreatQ sources, evaluated, prioritized, and even recommends action.

Mike Clark is an old friend. He and I were early guys in the Honeynet Project together years ago. Mike headed up development on the ThreatQ side. Mike, as always was a pleasure to work with. He worked closely with our team and within a couple of weeks we were integrated and running.

We've integrated with others. You can pull data from Threat Recon(R) from ThreatConnect, and limited data from Anomali, but ThreatQ really did it right. You get not only the indicators but the full range of collections, analysis, and human analyzed outputs in one pane of glass.

If you'd like to read more about the integration, or get more information on ThreatQ, one example of the integration is shown on Mike's ThreatQ blog.

If you'd like more information on Red Sky Alliance, our CTAC, shoot us a note. We're here to help.

Until next time,
Have a great week!
Jeff

The Camera Adds 20 Pounds!

Yesterday, WMUR, Manchester, NH's local ABC affiliate, released a three minute news piece on Wapack Labs.  As many of you who've done one of these television pieces know, they come on site and tape for three and a half hours and cut that down into a three minute piece. There's a ton of material that ends up being left on the cutting room floor. 

We were interviewed on the heals of Wannacry, and the WMUR folks, recognizing that NH is made up primarily of small companies, wanted to do the piece. 

During the morning of Wannacry, I'd been at three small local companies —all who'd been directly effected by the ransomware. In one, a florist, I'd spent 45 minutes waiting for an arrangement to be made up for my mothers 'celebration of life'.  While I waited and watched the floral designer piece the arrangement together, I chatted with the owner, who when she found out what I did, immediately told me that she'd lost her entire accounting, inventory, and customer list because the one computer used to run the business had been hit.  She had an IT consultant who was managing the systems, but the backups used to attempt the restore didn't work and they were forced to either pay, or reconsitute the drive through piecemeal backups and manual reentry, or, pay the ransom. 

Here's the math… 

• Pay $300 in ransom and get the key to simply unlock the system (and then go fire the IT consultant).
• Or spend days (more?) rebuilding the companies administrative operations. 

The company probably does $2 million per year in revenue; I'm guessing —it's a nice place and they're always hopping. At $2 mil per year, they generate approximately $5495 per day, and my bet is they make about 20% profit on that day — $1100 — after they pay their inventory (flowers come in daily), labor, etc. 

As the business owner, what would you do? 

As a security pro, what would you recommend? 

I recommended paying the ransom, then firing the IT consultant (I recommended a good one —a partner we've used in the past —Ezentria in Nashua), instructing the new IT consultant to build the system new and up to date, and getting back to business. 

DHS recommended (publicly, and spread by every news outlet out there) to NOT pay the ransom. Why? Because they take their outside council from larger companies who had full, clean backups and disaster recovery plans. Guess what? They don't need to pay the ransom. They were prepared and had a plan. 

In 2012, according to U.S. Census Bureau data, there were 5.73 million employer firms in the US. 99.7% of them had fewer than 500 employees. 89.6% had less than 20 workers. Add in the number of nonemployer businesses (solo practitioners) – there were 23.0 million in 2013 – and the number of US businesses with less than 20 workers increases to 97.9 percent. 

97.9% of companies are small businesses with less than 20 employees!  How many of them were consulted when DHS recommended that they not pay the ransom? Out of those, how many were prepared for a business critical ransomware attack? Not the ones we talked to that day. This florist could resort back to catalogs and the internet —and she did, but what about others who were stopped dead in their tracks? 

Look, there're a million ways to skin this cat, but common sense tells me that the DHS guidance doesn't apply to every company, and when a florist tells me that the government recommends she not pay the ransom (and take the $1100 per day hit to her bottom line), my stomach hurts and my face contorts. I can't help it. It's my natural reaction to stupidity. 

My point is, government paints with a very wide brush — from taxes to gun control to health care to cyber guidance. And for those companies who had strong Information Security teams who had kept the systems up to date, and had a good disaster recovery process, well, they weren't affected. For this who didn't, they were. And if that company didn't have backups, or a way to reconstitute data, and the system were business critical, what would be the right answer? What happens in this case, where Wannacry stopped business?

That day, the morning of Wannacry, we put up a website where we allowed users to contact us for help —for free. Some told us they were fine but wanted to know what to do for next time. Others had questions on their current state. We answered what we could and sent others a referral to Ezentria.

We thought WMUR did a terrific job on this. And thank you to Ezentria for handling any calls that we pushed their way. 

Until next time,

Have a great weekend!

Jeff

China’s Intelligence Networks in United States Include 25,000 Spies

Beijing's spy networks in the United States include up to 25,000 Chinese intelligence officers and more than 15,000 recruited agents who have stepped up offensive spying activities since 2012, according to a Chinese dissident with close ties to Beijing's military and intelligence establishment. This, in a piece where Bill Gertz, a long time Washington Times reporter and now writing for the Washington Free Beacon, interviews a Chinese dissident who reveals up to 18,000 Americans recruited as Chinese agents.

Without questioning Guo's motivations, the priority list that's played out in the last few years —in action, appears to be directly inline with what Guo talks about in his statements, and the aggressive positioning undertaken in their recent reorganization. We can't speak to the human rights abused claimed in the piece, for example "Chinese intelligence officers sent to the United States are controlled by the MSS by keeping all their family members and relatives hostage"  but according to Guo:

• China's intelligence targets included several strategic areas of the United States.
• "The first is to obtain military weapons-related technology. This is priority No. 1," Guo said.
• Second, Chinese intelligence is engaged in "buying" senior U.S. officials personally, 
• and a third objective is buying family members of American political or business elites "with a view to getting intelligence and to make big business deals in China's favor," he said.
• A fourth priority is penetrating the American internet system and critical infrastructure by implanting malicious software.
• "And they have successfully penetrated all the major defense weapons suppliers of the U.S. government," Guo said, adding that "the scale of their operations is mind boggling."

Guo said Ma, the MSS vice minister, told him that a major shift by the Chinese was expanding the scope of agent recruitment from Asians to mainstream ethnic groups.

"This is where the biggest danger lies," he said. "It's clear the situation is getting more and more dangerous now. The United States has the best weapons in its arsenal, such as laser weapons, etc. Yet, the Chinese spy system has penetrated into the bloodstream of American defense establishment with their viruses and everything else."

"The United States is bleeding and is unaware that sooner or later the United States will run out of blood," Guo said.

Also, the United States is overly reliant on technical spying while China has an asymmetrical advantage in using its tens of thousands of human spies.

On June 26th, Wapack Labs published a top down report on the Chinese reorganization of their new cyber structure. The report summarizes Wapack Labs research conducted on the PLA Third Department, suspected of being the primary military cyber force for China.  The research was conducted entirely on open sources available on the Chinese Internet, plus unclassified satellite imagery.  The report is unclassified but sensitive in that it reveals more about Chinese cyber-related military facilities than has been published in the past.  This is a compilation of recent Wapack Labs reporting separately on each of these Third Department entities.  If you'd like a copy of the report, register, and we'll send you one.

VIDEO: Integrated with ThreatQ with raw collection data (CORRECTED COPY)

Sorry folks. I realized I mixed up the link to the video. Let's try this again.

-----------------------------------------------

A few months ago, a good friend told me that he really loves the quality of our reporting, but that we really needed to figure out out to get it into systems.  I've been wanting to see this happen for the last coupe of years, but we've finally, completely integrated into ThreatQ.

Why'd it take so long? We needed our own APIs to allow ThreatQ to be able to pull, and now with CTAC online, the ability to integrate becomes much easier.

So rather than write an entire blog, and hope you read it, I've put up a video of Micheal Clark at our last Threat Day, where he walks users through pulling Wapack Labs intelligence into ThreatQ.

Enjoy.

Jeff

Risk Management, Compliance, Resilience. What's old is new again!

Three times this week a user or potential customer told me I'm not looking for more intelligence. I'm looking for compliance, risk management, resiliency.

Imagine that! Those are the three things that that we talk about most… well, may be not resiliency. Your failover is something completely out of my control, but for over 20 years I've had a copy of ISACA's Enterprise Risk Management framework documents either on, or very close to my desk. I'm a long time user of SEI'S OCTAVE Risk Modeling system —even though it's morphed, it's easy to explain, use, and train a team to implement. And compliance? That's pretty easy. If I see massive amounts of lost PII, intellectual property or outbound activities touching our sinkholes, it's pretty easy to know who's in compliance and who's not.  I don't see the systems, but I definitely see the outputs.

I have to laugh. I consider myself an expert in risk management. I have an MBA with a focus in risk, and have built and implemented risk models at some of the best companies, on three different occasions.

I've been interested in, and preaching risk management since 1998, first using OCTAVE as a Navy Officer, implementing risk management into Navy Networks through a visiting scientist partnership with SEI. This work lead into processes for building SiLK models (Suresh L Konda's network flow engine —a CMU PhD and good friend) —now Centaur and Einstein.

Later, after leaving the Navy and working for Cisco (2001-2005) I built a team and implemented hybrid OCTAVE, COSO, and ISO models to build risk processes. This hybrid model was used to evaluate M&A prospects, third party partners and suppliers, and remote offices. We used these models in dozens of locations and organizations in as many countries around the world. Risk is a common language transcending country borders.

At Northrop Grumman (2005-2008), I built on these processes using ISACA's early Enterprise Risk Management framework —a larger view designed to integrate IT Risk into larger organizational risk models —financial, operational, etc. We used it to evaluate (again) M&A candidates, third party partners and suppliers and remote offices. And when it came time to chase out bad guys, we already knew the issues with the infrastructure in which we were operating. This product evolved into full-out, large scale risk management and identification run by my second team hire.

Yep. This stuff works.

But guess what all three of these have in common?

Every one requires a deep understanding of external threats —to operations, to finance, and to IT. That information is called intelligence, and it's a linch-pin component of every risk management process. No matter which one you choose, they all require external inputs to understand and prioritize the threat, the strategy, and the spend that will go into mitigating, minimizing, transferring (through insurance), or accepting the risks identified.

Without intelligence, you can't have risk management, and therefore can not have either compliance or resilience. Intelligence is foundational.  And if you're relying on intelligence that comes in that sexy little silver UTM (we use one too!), you're missing the boat. Are you going to show your boss the UTM logs when you need budget for next year's threats? Probably not.

You need to think strategically, and that requires good intelligence —the story behind the threat, the motivation of the bad guys chasing you, maybe a picture of one or two of those guys, and an understanding of how they'll affect your business --not just a feed of IOCS.

An as is always the theme of my blog… we're here to help.

Wapack Labs Cyber Threat Analysis Center is a great way for companies of any size to be constantly aware of threats you face.  Whether it's monitoring threats to key personnel, stolen credentials, sinkhole analysis, or sentiment analysis, CTAC makes it easy to monitor your daily and ongoing threat picture. Look at five years worth of data and extrapolate that out into longer term planning. Request a deep dive on your company and use that in planning futures. We've published on everything from stolen credit cards to North Korean Nuclear and EMP options. We've covered Ukrainian | Russian geopolitical risk monitoring for our companies who do work in the area, and published lists and mitigations for cyber tools being hoarded by Iranian hackers during last year's nuclear talks. We publish indicators with confidence ratings, key logger dumps (not TOR captures with high false positives), and probably have one of the largest sinkhole collections going.

Risk Management, Compliance, Resilience. As you think through these processes and need to figure out who to call for intelligence inputs, call us first.

Want a demo? Drop us a note. We're hear to help.

Wannacry —I know, it's getting old already right? Read this...

On 02 Jun 2017 Wapack Labs obtained several sinkholes associated with the Virut botnet and were able to confirm that the botnet is being used to deliver the Wannacry ransomware.  Because the botnet owners are paid by the number of installs, Wannacry is now being deployed globally, and fast. Wapack Labs has reason to believe that Wannacry is now affecting banks and ATM machines, are specifically infecting companies in the Middle East and Northern Africa region.

Why should you care? Virut has been around since at least 2006, and although suffering a 2013 takedown by the Polska CERT, has resurfaced and remains one of the most prevalent distribution networks for spam, phishing, malware, etc… and now, ransomeware. Wannacry is now being spread far and wide, and if you've not installed the patch, there's a high probability that you're about to learn a hard lesson in network hygiene. 

And so for now, this ends our public service announcement. 

As an aside, and a bit of a science experiment, we're experimenting with some rudimentary artificial intelligence and publishing capabilities. One, is one of the earliest and simplest forms. We've loaded a public (and gratis) version of MediaWiki in an effort to encourage massive crowdsourcing. We call it Wapackapedia(R). Yes, there are LOADS of issues with sharing information like this; it's definitely a Bambi but in cases like this, where hundreds of thousands more computers are now carrying dormant versions of Wannacry, my science experiment goes like this… Get the damn word out!

Here's the link:  https://wapackapedia.wapacklabs.com/Wannacry

I also published two other pages.. mostly with computer generated work but one page has some new and interesting stuff on Lazarus (North Korean APT).

Here's that link:  https://wapackapedia.wapacklabs.com/Lazarus

I'm looking for maximum crowdsourcing. You guys know me enough.. I believe in machine to machine interfacing but my belief is that real value comes from human communication first, then distilled into machine readable stuff.  Of course, any victim information is not posted here. As always, we prefer to not out victims publicly —they've been victimized once already. For that, we've built out private locations behind our Red Sky curtain where we notify our members.

As always, if you'd like to know more, reach out. Jim's the new President and will be happy to set you up with a demo. He can be reached at jmckee@wapacklabs.com.

Stutzman assumes new role...

What's that all about?

I've been running Red Sky and Wapack Labs since Feb '12 after leaving the government to join my old friend Jim McKee. I enjoy building new things, but long term? I needed a break. I keep finding myself with one foot in the analytic camp and one foot in the management camp, but as the company grows it becomes harder and harder to do both things well.

This week I told my partners that I felt like I was getting dumber with every day that passed, and

every minute that I dealt with prospecting, taxes, managing the team, and all of the other things that go along with being CEO, I miss out on time spent staying sharp on the things that I really love doing.

So on Monday, I turned over to Jim McKee, anointed him President, and started writing analysis.

My first task? I convened a fusion cell and authored a weekly report —one that we push out to customers who use us for tailored intelligence. I'd forgotten how much fun it is, but also it's like going back to working out after being off for a while —your muscles hurt afterward! Yes, my brain hurts tonight but it's a good hurt.

So, CEO? Not me. Chief, Intelligence Operations? Oh yeah…

Tanqueray Martini. Shaken, not stirred.

CloudHopper? Systemic... AND Stutzman assumes new role!

This is an excerpt from a piece we authored for our membership. CloudHopper, first discussed about a month ago by PwC UK and BAE are targeting Managed Service Providers for VPN and RDP credentials. Brilliant. When I first read the piece I assumed this to mean Managed Security Service Providers had been targeted.. which would be bad, but colocation facilities? Not a new TTP but still brilliant. 

"CloudHopper, a new name for APT 10 has been identified stealing VPN/Remote Desktop credentials from Managed Service Providers in an effort to obtain administrative level direct access to network infrastructure mechanisms. In our opinion, this is significant. In almost every presentation, at least one financial presenter talks about “systemic threat”. This, we believe, is the epitome of systemic –get the administrative credentials to the network perimeter, change the authentication, and obtain unfettered, unchallenged access to any of the MSP’s customer base. (View the full report: https://community.redskyalliance.org/docs/DOC-5046)"

This actually scares the hell out of me. 

Four years ago we rented colo-space for a malware analysis sandbox. The colo-provider had all of the right words in their list of certifications —ISO 27001, PCI, HIPAA, etc. After a walk-around of the facility, we signed the contract for a two year stint. 

Within a month we started noticing fun things happening on the box. Fortunately for us we hadn't opened it up for our Red Sky membership; we were still very much in our testing phase. It was clear to us however that the machine had been compromised —so we drove to Boston, removed the server from the rack and brought it back to Manchester where we mounted it locally. We found that the colo had the necessary tools to monitor the systems, but not monitor the security. In fact, they had all of the right tools and skills, but never monitored for the things that would have allowed them to see unauthorized access —something we'd paid for. 

The idea that VPN/RDP credentials are stolen and pathways are used is not at all new. In fact, these were the first cases that I can remember after building my APT team when I worked at 'that really big defense contractor', over ten years ago. These accounts are most prized, and in many cases in large companies administrative credentials —domain credentials —those that most often have VPN and RDP access to many many servers across the horizontal become one of the single most effective vectors for systemic breach. And when it's done in a colocation facility where small and medium sized companies are most likely to host? Not new, but still brilliant. 

When asked why he robbed banks, Willie Sutton replied, “I rob banks because that’s where the money is.”  Why target colo facilities? Because that's the pathway to small company innovation and potentially, larger accesses. 

BT

This may or may not be a surprise to many of you, but I've been running Red Sky and Wapack Labs since February 2012 when I joined my old friend Jim McKee in building Red Sky. 

This week I told him that I felt like I was getting dumber with every day that passed, and that every minute that I dealt with prospecting, taxes, managing the team, and all of the other things that go along with being CEO, I miss out on time spent staying sharp on the things that I really love doing.

So on Monday I anointed him President, and started doing analysis again. I'd forgotten how much fun it is, but also it's like going back to working out after being off for a while —your muscles hurt afterward! Yes, my brain hurts tonight but it's a good hurt.

My first task? We write tailored weekly products as an intelligence provider to some big companies. Yesterday I wrote my first one in nearly six months. There are several more to come. 

So, CEO? Not me. Chief, Intelligence Operations? Oh yeah…

Tanqueray Martini. Shaken, not stirred.

#WannaCry - To Pay or Not to Pay. That is the question...

I'm not always sure that the government offers the best advice… and the press simply repeats it.

Earlier the week I was interviewed by the local ABC Affiliate. The next day, my team pulled together roughly 40 Red Sky Alliance members for a  —largely on my request to better understand and make sense of all of the noise in the press. 


Yesterday, I picked up flowers at a local shop, when one of the owners approached. She'd seen me on WMUR and wanted to tell me that she'd also experienced a WannaCry incident. This was the third such mention by someone who'd been infected. None of the three had full backups. All three told me that because 'they' (meaning the press, largely because of circular reporting) had instructed victims to not pay the ransom. I handed them a business card and told them to call me Monday.

I have a few thoughts. 

1. Don't pay? Be careful. Large companies, and those smaller companies who are prepared for such an event might be fine not paying the ransom. What's 'prepared' mean? It means that you can completely restore lost data from tested backups. In these cases, none of the three had complete backups. They will soon. Each lost far more revenue than they would have if they'd have just paid the ransom.

2. Make your own decisions. The government doesn't run your business. The press only reports what others tell them. Many times those opinions are based on something reported by others —often times coming directly from the government. In this case the government urges people to not pay the ransom. The US does not negotiate with . I would urge you to make you own decisions. 

3. Who did this? I'm not sure anyone has any real evidence. One report compared WannaCry with Lazarus, but in our work, we found only six lines of code in common —largely machine generated; and our opinion, not a good indicator. We discounted it. We do however have theories… we rarely look at attribution at the country level (i.e.: Russia, China, N. Korea). I prefer to look for individuals. In this case, I think the story will unfold. My team, and our Red Sky members, are watching to see if this is a test. My bet? There'll be more. 

WannaCry encrypted over 200,000 computers. Last heard, the attackers earned slightly over $75,000 US. Not a bad payday if you're sitting in someones garage punching a keyboard. Not so good if it's a country attempting to steal money (N. Korea?). 

The bigger lesson? I have two. First, small business owners listen to the government, but in this case, the government (and repeated by the press) didn't give adequate guidance to small businesses. In fact, Here's what the US-CERT offered as guidance:

"Paying the ransom does not guarantee the encrypted files will be released; it only guarantees that the malicious actors receive the victim’s money, and in some cases, their banking information. In addition, decrypting files does not mean the malware infection itself has been removed."

One, me, might argue that in this case, this guidance is only partially true. Let's break this down.

Paying the ransom does not guarantee that the encrypted files will be released...

… this to me demonstrates a lack of basic understanding on the part of US-CERT. Ransomware is a customer service business. A few weeks back, we paid a ransom for a client --roughly $30,000. When we couldn't decrypt servers we contacted their tech support. YES! They have TECH SUPPORT!. If someone pays and still can't get their stuff back, victims will stop paying. It's bad for business!

…it only guarantees that the malicious actors receive the victim’s money, and in some cases, their banking information.

I'm sorry. Did I miss something? In which case did WannaCry take someones banking information? Here's the way you buy a BitCoin… Go to an exchange, pay the money, take a picture of yourself with a note that clearly states that you want to purchase the BitCoin (the picture/note combination will be given to PayPal or your credit card company in the event that you try and reverse the purchase). You then get credited with the BitCoin —in a personal digital wallet. Send the bitcoin to the bad guy, and you're done. So where does my bank account get stolen?

In addition, decrypting files does not mean the malware infection itself has been removed.

This is absolutely true. Even if you pay, you'll want to burn that machine to the ground and reload it. 

Two of three pieces of guidance offered by US-CERT were not completely true, and in fact (again, Stutzman's humble opinion) poorly worded guidance. If US-CERT is going to be cited as the authority (and they SHOULD BE!), they really need to pay attention to their audience. Never, EVER give guidance to one company and expect it'll hold true to another. 

I'm certain there are victims out there still reeling from the encryptor. Drop us a note.