Securosis

Research

Firestarter: Black Hat and AI… What Could Go Wrong?

In this episode we review the lessons of this year’s Black Hat and DEF CON. In particular, we talk about how things have changed with the students we have in class, now that we’ve racked up over 5 years of running trainings on cloud security. then we delve into one of the biggest, and most confusing, trends… the mysteries of Artificial Intelligence and Machine Learning. Considering our opinions of natural intelligence, you might guess where this heads… Watch or listen: Share:

Share:
Read Post

Firestarter: It’s a GDPR Thing

Mike and Rich discuss the ugly reality that GDPR really is a thing. Not that privacy or even GDPR are bad (we’re all in favor), but they do require extra work on our part to ensure that policies are in place, audits are performed, and pesky data isn’t left lying around in log files unexpectedly. Watch or listen: Share:

Share:
Read Post

The Security Profession Needs to Adopt Just Culture

Yesterday Twitter revealed they had accidentally stored plain-text passwords in some log files. There was no indication the data was accessed and users were warned to update their passwords. There was no known breach, but Twitter went public anyway, and was excoriated in the press and… on Twitter. This is a problem for our profession and industry. We get locked into a cycle where any public disclosure of a breach or security mistake results in: People ripping the organization apart on social media without knowing the facts. Vendors issuing press releases claiming their product would have prevented the issue, without knowing the facts. Press articles focusing on the worst case scenario without any sort of risk analysis… or facts. Plenty of voices saying how simple it is to prevent the problem, without any the concept of complexity or scale of even simple controls (remember kids, simple doesn’t scale). To be clear, there are cases where organizations are negligent and try to cover up their errors. If a press release says things like “very sophisticated attack”, infosec fairies deservedly lose their wings, but more often than not we focus on blame rather than cause. This is true both in public and for internal investigations. This is a problem many industries have faced; two in particular have performed extensive research and adopted a concept called Just Culture. It’s time for security to formally adopt Just Culture, including adding it to certifications and training programs. Aviation and healthcare are two professions/industries which use Just Culture, to different degrees. My background and introduction is on the healthcare side so that’s where I draw from. First, read this paper available through the National Institutes of Health: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3776518/. The focus in Just Culture is to identify and correct the systemic cause, not to blame the individual. Here are some choice quotes: People make errors. Errors can cause accidents. In healthcare, errors and accidents result in morbidity and adverse outcomes and sometimes in mortality. One organizational approach has been to seek out errors and identify the responsible individual. Individual punishment follows. This punitive approach does not solve the problem. People function within systems designed by an organization. An individual may be at fault, but frequently the system is also at fault. Punishing people without changing the system only perpetuates the problem rather than solving it. … A just culture balances the need for an open and honest reporting environment with the end of a quality learning environment and culture. While the organization has a duty and responsibility to employees (and ultimately to patients), all employees are held responsible for the quality of their choices. Just culture requires a change in focus from errors and outcomes to system design and management of the behavioral choices of all employees. … In a just culture, both the organization and its people are held accountable while focusing on risk, systems design, human behavior, and patient safety. The focus is on systemic risk first, and individual… later. This is something we face in healthcare/rescue every day, where many errors result from the system more than the person. For example in some prehospital systems it isn’t uncommon to have two medications with vastly different effects in very similar packaging, resulting in medication errors which can be fatal. That answer isn’t better training but better packaging. Fix the system – don’t expect perfect behavior. Let’s apply this to Twitter. Plain text passwords were stored in logs. This is bad, but there are many ways it could have happened. Think of all the levels of logging and software components they have, and all the places passwords might have fallen into logs. Using a Just Culture approach we should reward Twitter for their honesty, and learn what techniques they used to detect the exposed data, and what allowed it to be saved in those logs, undiscovered for so long. What system issues caused the problem, and how can we prevent them moving forward? Not “Twitter was stupid and got hacked” (because apparently they weren’t). Just Culture is about fostering an open culture of safety where mistakes – even individual mistakes – are used to improve overall system resilience. It’s our time. Share:

Share:
Read Post

Firestarter: The RSA 2018 Episode

This week Rich, Mike, and Adrian talk about what they expect to see at the RSA Security Conference, and if it really means anything. As we do in most of our RSA Conference related discussions the focus is less on what to see and more on what industry trends we can tease out, and the potential impact on the regular security practitioner. For example, what happens when blockchain and GDPR collide? Do security vendors finally understand cloud? What kind of impact does DevOps have on the security market? Plus we list where you can find us, and, as always, don’t forget to attend the Tenth Annual Disaster Recovery Breakfast! Watch or listen: Share:

Share:
Read Post

Firestarter: Old School and False Analogies

Old School and False Analogies This week we skip over our series on cloud fundamentals to go back to the Firestarter basics. We start with a discussion of the week’s big acquisition (like BIG considering the multiple). Then we talk about the hyperbole around the release of the iBoot code from an old version of iOS. We also discuss Apple, cyberinsurance, and the actuarial tables. Then we finish up with Rich blabbing about lessons learned as he works on his paramedic again and what parallels to bring to security. For more on that you can read these posts: https://securosis.com/blog/this-security-shits-hard-and-it-aint-gonna-get-any-easier and https://securosis.com/blog/best-practices-unintended-consequences-negative-outcomes Watch or listen: Share:

Share:
Read Post

Best Practices, Unintended Consequences, and Negative Outcomes

Information Security is a profession. We have job titles, recognized positions in nearly every workplace, professional organizations, training, and even some fairly new degree programs. I mean none of that sarcastically, but I wouldn’t necessarily say we are a mature profession. We still have a lot to learn about ourselves. This isn’t unique to infosec – it’s part of any maturing profession, and we can learn the same lessons the others already have. As I went through the paramedic re-entry process I realized, much to my surprise, that I have been a current or expired paramedic for over half the lifetime of that profession. Although I kept my EMT up, I haven’t really stayed up to date with paramedic practices (the EMT level is basically advanced first aid – paramedics get to use drugs, electricity, and all sorts of interesting… tubes). Paramedics first appeared in the 1970s and when I started in the early 1990s we were just starting to rally behind national standards and introduce real science of the prehospital environment into protocols and standards. Now the training has increased from about 1,000 hours in my day to 1,500-1,800 hours, in many cases with much higher pre-training requirements (typically college level anatomy and physiology). Catching back up and seeing the advances in care is providing the kind of perspective that an overly-analytical type like myself is inexorably drawn toward, and provides powerful parallels to our less mature information security profession. One great example of deeper understanding of a consequence of the science is how we treat head injuries. I don’t mean the incredible, and tragic lessons we are learning about Traumatic Brain Injury (TBI) from the military and NFL, but something simpler, cleaner, and more facepalmy. Back in my active days we used to hyperventilate head injuries with increased intracranial pressure (ICP, because every profession needs its own TLAs). In layman terms: hit head, go boom, brain swells like anything else you smash into a hard object (in this case, the inside of your own skull), but in this case it is swelling inside a closed container with a single exit (which involves squeezing the brain through the base of your skull and pushing the brain stem out of the way – oops!). We would intubate the patients and bag them at an increased rate with 100% oxygen for two reasons – to increase the oxygen in their blood, trying to get more O2 to the brain cells, and because hyperventilation reduces brain swelling. Doctors could literally see a brain in surgery shrink when they hyperventilated their patients. More O2? Less swelling? Cool! But outcomes didn’t seem to match the in-your-face visual feedback of a shrinking brain. Why? It turns out that the brain shrinks because when you hyperventilate a patient you reduce the amount of CO2 in their blood. This changes the pH balance, and also triggers something called vasoconstriction. The brain sank because the blood vessels feeding the brain were providing less blood to the brain. Well, darn. That probably isn’t good. I treated a lot of head injuries in my day, especially as one of the only mountain rescue paramedics in the country. I likely caused active harm to these patients, even though I was following the best practices and standards of the time. They don’t haunt me – I did my job as best I could with what we knew at the time – but I certainly am glad to provide better care today. Let’s turn back to information security, and focus on passwords. Without going into history… our password standards no longer match our risk profiles in most cases. In fact we see these often causing active harm. Requiring someone to come up with a password with a bunch of strange characters and rotate it every 90 days no longer improves security. Blocking password managers from filling in password fields? Beyond inane. We originally came up with our password rules due to peculiarities of hashing algorithms and password storage in Windows. Length is a pretty good one to put into place, and advising people not to use things that are easy to guess. But we threw in strange characters to address rainbow tables and hash matching. Forced password rotations due to letting people steal our databases, and then having time to brute force things. But if we use modern password hashing algorithms and good seeds, we dramatically reduce the viability of brute force attacks, even if someone steals a password. The 90-day and strange character requirements really aren’t overly helpful. They are actually more likely harmful because users forget their passwords and rely on weaker password reset mechanisms. Think the name of your first elementary school is hard to find? Let’s just say it ain’t as hard to spot as a unicorn. Blocking password managers from filling fields? In a time when they are included in most browsers and operating systems? If you hate your users that much, just dox them yourselves and get over it. The parallel to treatment protocols for head injuries is pretty damn direct here. We made decisions with the best evidence at the time, but times changed. Now the onus on us is to update our standards to reflect current science. Block the 1234 passwords and require a decent minimum length; but let users pick what they want and focus more on your internal security and storage, seeds, and hashing. Support an MFA option appropriate to the kind of data you are working with, and build in a hard-to-spoof password reset/recovery option. Actually, that last area is ripe for research and better options. We shouldn’t codify negative outcomes into our standards of practice. And when we do, we should recognize and change. That’s the mark of a continuously evolving profession. Share:

Share:
Read Post

Firestarter: Best Practices for Root Account Security and… SQRRL!!!!

Just because we are focusing on cloud fundamentals doesn’t mean we are forgetting the rest of the world. This week we start with a discussion over the latest surprise acquisition of Sqrrl by Amazon Web Services and what it might indicate. Then we jump into our ongoing series of posts on cloud security by focusing on the best practices for root account security. From how to name the email accounts, to handling MFA, to your break glass procedures. Watch or listen: Share:

Share:
Read Post

Firestarter: Architecting Your Cloud with Accounts

We are taking over our own Firestarter and kicking off a new series of discussions on cloud security… from soup to nuts (whatever that means). Each week for the next few months we will cover, in order, how to build out your cloud security program. We are taking our assessment framework and converting it into a series of discussions talking about what we find and how to avoid issues. This week we start with architecting your account structures, after a brief discussion of the impact of the Meltdown and Spectre vulnerabilities since they impact cloud (at least for now) more than your local computer. Watch or listen: Share:

Share:
Read Post

This Security Shit’s Hard and It Ain’t Gonna Get Any Easier

In case you couldn’t tell from the title, this line is your official EXPLICIT tag. We writers sometimes need the full spectrum of language to make a point. Yesterday Microsoft released a patch to roll back a patch that fixed the slightly-unpatchable Intel hardware bug because the patch causes reboots and potential data loss. Specifically, Intel’s Spectre 2 variant microcode patch is buggy. Just when we were getting a decent handle on endpoint security with well secured operating systems and six-figure-plus bug bounties, this shit happened. Plus, we probably can’t ever fully trust our silicone or operating systems in the first place. Information security is hard. Information security is wonderful. Working in security is magical… if you have the proper state of mind. I decided this year would be a good one for my mid-life crisis before I miss the boat and feel left out. The problem is that my life is actually pretty damn awesome, so I think I’m just screwing up my crisis pre-requisites. I like my wife, am already in pretty good physical shape, and don’t feel the need for a new car. Which appears to knock out pretty much all my options. The best I could come up with was to re-up my paramedic certification, expired for 20 years. After working at the paramedic level again during my deployment to Puerto Rico it felt like time to go through the process and become official again. One of my first steps was to take a week off infosec and attend a paramedic refresher class. A refresher class is an entirely different world than initial training. It’s a room full of experienced medics who are there to knock out the list of certifications they need to maintain every two years. Quite a few of the attendees in my class started working around the same time as me in the early 1990’s. Unlike me they stuck with it full-time and racked up 25 years or more of direct field experience. There are no illusions among experienced medics (or firefighters or cops). If you go in thinking you are there to save lives you are usually out of the job in less than five years. You can’t possibly survive mentally if you think you are there to save the world, because once you actually meet the world, you realize it doesn’t want saving. The best you can usually do is offer someone a little comfort on the worst day of their life, and, maybe, sometimes help someone breathe a little longer. You certainly aren’t going to change the string of bad life decisions that led you to their door. Bad diet, smoking, drugs, couch potatoitis, whatever. Not that everyone dials 911 as the result of seemingly irreversible decisions, but they do seem to take a disproportionate amount of our time. You either learn how to compartmentalize and survive, or process and survive, or you get another job. Even then it sometimes catches up to you and you eventually leave or kill yourself. Suicide is a very real occupational hazard. Then there are new illnesses, antibacterial resistance, new ways of damaging the human body (vaping, exploding phones, airbags, hoverboards), the latest drug crisis, the latest drug shortage, ad infinitum. On the other side we have new drugs, new monitoring tools, new procedures, and new science. For me this maps directly to the information security professional mindset. As long as there are human beings and computer chips we will never win. There will never be an end. We face an endless stream of challenges and opportunities. Some years things are better. Other years things are worse. The challenge for us as professionals is to decide the role we want to play and how we want to play it. There are EMS systems which still use proven bad techniques because someone in charge learned it, then decided they don’t want to change. Maybe due to sunk cost bias, maybe due to stubbornness. I know it was hard to learn that the technique I used to help the 14-year-old massive head injury patient 20+ years ago likely contributed to his permanent mental deficit. Not that I did anything wrong at the time, but because the science and our knowledge and understanding of the physiological mechanisms in play changed. I hurt that patient, while providing the best standard of care at the time. Our password policies made sense at the time, but now we need to move past encoding unmemorable 8-character passwords rotated every 90 days into standards, and update our standards to reflect the widespread adoption of MFA and the latest password hashing mechanisms. We don’t need to accept that there is literally no need for a DMZ in the cloud we just need to architect properly for the cloud. We need to accept that Meltdown, ,Spectre and whatever new hardware vulnerabilities appear are out of our control, but we still need to do our best to mitigate the risk. The bad medics aren’t the new medics or the old medics, but the medics who can’t accept that people don’t really change, and everything else does. Security is no different. In both professions the best leaders are those who continue to push themselves and adapt without burning out permanently. This is especially true for security today, as we face the biggest technology shifts in the history of our profession, while nation-states and extremely well-funded criminals keep raising the stakes. But there is one key difference between being a paramedic and being a security professional (beyond pay). As a paramedic I may help someone with pain during the worst 10 to 60 minutes of their life, then move on to the next call. As a security professional I can help millions, if not billions (hello Amazon, Facebook, Apple, and Google Security), at a time. I find this especially rewarding and exciting, especially as we build new products we think can have major impacts at scale – but even if that doesn’t work, I know that

Share:
Read Post

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.