Feeds:
Posts
Comments

Archive for the ‘Computers’ Category

If a Picture is Worth a Thousand Words …

Posted in Cybersercurity, Education, General, tagged , , on 03 Sep 2023| Leave a Comment »

I’ve not been posting much as of late. Actually, it’s been quite some time.

It’s not for lack of things to write about. I’ve got about thirty books that I need to write reviews for. I have a bunch of things I’d like to write about concerning threat modeling and cybersecurity more broadly.

I’ve been putting all my creative energy over the past three and a half years into the care and feeding of the Autonomous Vehicle Cybersecurity Development Lifecycle (AVCDL). It’s been a huge undertaking. I’ve learned a great deal throughout its creation and defense. It’s been assessed twice now against an international technical standard (ISO/SAE 21434) and a global regulatory one (UN R155). I’ve created over a thousand pages of documentation embodied in nearly a hundred different documents. I’ve created two visual languages to be able to communicate the concepts it contains. Most recently, I’ve been working on the creation of training materials to go along with it. I’ve also given presentations on in and a few weeks ago been interviewed regarding the assessment process.

This brings me back to why I’m writing this post. I’ve created a new page to track all the videos I’m either in or responsible for, and wanted to give it some visibility. I’m not expecting a huge uptick in view, but it’s nice to have this information in one place.

Read Full Post »

Why Do We Threat Model?

Posted in Computers, Cybersercurity, threat modeling, tagged , , on 20 Jun 2021| Leave a Comment »

I’ve only been threat modeling for about a decade. In that time, I’ve rarely seen threat modeling used as intended. Why is that and why do we threat model in the first place?

Lately everyone seems to have jumped on the threat modeling bandwagon. Every new certification wants to see a box ticked for threat modeling, so companies are scrambling to make that happen. But many times this means that companies are threat modeling after they’ve finished development. Does that even make sense? Let’s take a step back and ask the question, “Why are we doing this?”

Every development team understands unit testing. They get static analysis. Conceptually, they appreciate penetration testing, if not what it’s limitations are. But when it comes to threat modeling, you get more hand waving than a cruise ship departure.

There’s no end to the number of misconceptions regarding threat modeling. Some see it as a one-time, rubber stamp on the product’s security. Others believe that it must expose all known issues in order to be considered valid. Still others believe that if they contribute a component, that they are exempt from threat modeling because it will be done at the system level. And so forth. The underlying problem is not that all of these ideas are wrong, it’s that people don’t know why threat modeling exists.

First, threat models are only useful if they evolve with the product’s design. Not the implementation, but the design. Why? Because the point of threat modeling is to evaluate the design. The outcome of the exercise is a set of design deficiencies. Note that this is a very different thing from what a penetration test discovers. You can have a perfect design and still find issues during penetration testing, because it can identify errors in implementation. Since the threat model uses an idealization of the systems for its analysis, that isn’t possible.

Second, threat models focus us on best practices by forcing us to consider the decomposition of the system, the trust boundaries, and data flows. A threat model won’t ask if we’re using 4096-bit keys. It will ask if we have appropriate controls. Controls imply requirements, specifically, non-functional security requirements. That’s a topic for another day.

Third, threat models allow us to systematically and consistently consider the system. These are two very important elements. One of the questions we seldom ask properly is “How do we know we have security coverage?” Since threat modeling deals with a model of the system, the answer is once we’ve iterated over all the data flows in all the workflows of the system. Good luck doing that with penetration testing. The second element is equally important. Threat modeling is only useful if it produces consistent repeatable results. That means how we undertake the exercise matters. In my opinion, any moderately trained individual should be able to get the same results out of a threat model as some of equal training. Will there be deviations, sure. Should they be substantive? No.

I’ve always found it frustrating when people expect threat models to identify all know issues. This is both unhelpful and unnecessary. It’s unhelpful, because it implies an over-tuned analysis process that probably won’t work if things change. It’s unnecessary because as mentioned issues that are known are known. Especially if said issues are identified in testing, since you already have coverage. Also, they tend to be implementation issues.

One of the difficulties in the threat modeling process is that is not only exposes design deficiencies, but also that it exposes a lack of design process. In a hyper-full-stack-focused world, many have forgotten that agile doesn’t mean that you just build until it works and document as implemented. That kind of sloppy engineering doesn’t fly when safety is an issue. You can be agile, but all the forms still apply. An advantage in incorporating threat modeling into an agile design process is that since you’re system is by definition smaller, there’s less to model. Additionally, if you’re using compositional threat modeling, things can go really quickly. It’s elementary network theory.

The final thing I’ll bring up is cost. We threat model to save time and money. There’ve been multiple studies showing that the further along the process is when you identify an issue (especially in the underlying design) the more expensive it is to mitigate. And who doesn’t like to save money. Well, project management, I suppose, they just want to save time.

This post is a bit different from my usual link-laden ones, but I’ve been thinking about big picture stuff lately.

References

The Thinker, photo by Andrew Horne (public domain)
https://commons.wikimedia.org/wiki/File:The_Thinker,_Rodin.jpg

Read Full Post »

At Depth Compositional Threat Modeling

Posted in Computers, Cybersercurity, threat modeling, tagged , , , , , , , , , , on 13 Jun 2021| Leave a Comment »

In my previous post, Line Upon Line: Compositional Threat Modeling, I made the case for compositional threat modeling (CTM). In this post, I’ll explore how CTM is already being used unintentionally and why we need to adopt an intentional approach.

It’s one thing to suggest that we should be intentional in our use of CTM, but quite another to assert that we’ve been using it already. That’s very true. Let me explain. I will, of course incorporate a bit of personal history, music and seamless plugs. If you stay with me on this, you’ll be treated to a cross between James Burke– and Carl Sagan-esque tale weaving.

In the early 1980s, I read Ken Thompson‘s Turing Award Lecture, Reflections on Trusting Trust. In it, Thompson describes how the C compiler itself can be compromised in what we would today describe as a supply chain attack. I never again looked at my development tools in the same way. Up until that point in time, I’d never considered that the very tools I used to build secure systems could betray me, but in that lecture, Thompson made it very clear that I’d created a model of the world that was just wrong. And this gets to the heart of why CTM is important.

When we undertake the threat modeling activity, we are reasoning on a model of the design of a system. Note that there were two levels of indirection in that statement. That’s important. Essentially, we’re reasoning on a model of a model. This is the point at which I’ll shamelessly plug Adam Shostack for his shout out to George Box for observing, “All models are wrong but some are useful.” As to why this is an important observation we need to consider what Alan Turing wrote twenty-five years prior in his 1951 paper The Chemical Basis of Morphogenesis.

“This model will be a simplification and an idealization, and consequently a falsification. It is to be hoped that the features retained for discussion are those of greatest importance in the present state of knowledge.”

It’s important to keep in mind that the model is a lie that we hope keeps sufficient features as to be useful. Problems occur when we forget that and start treating the model as though it were the actual system. To quote Alfred Korzibsky, “a map is not the territory.”

In order for us to reason on the security of the design of a system, we discard most of the information regarding both the system and its design. And that’s okay, so long as the features retained for discussion are those of greatest importance in the present state of knowledge with respect to security.

Unfortunately, in the process of our relatively recent adoption of threat modeling as a security activity, we seem to have taken the approach called out in The Alan Parsons Project 1985 album Stereotomy song In the Real World: “Don’t wanna live my life in the real world.” By this I mean that the models that we’re working with contain fewer feature than needed to produce sufficiently expressive results.

This is not to say that all the threat modeling results we get on a daily basis are bad. We can keep the baby and not drink the bath water. We’ve been leaving stuff out. And some of that stuff is important. What’s more important though is that the consumers of the issues identified by the threat models generally believe that we’ve completely juiced that orange.

This brings us back to Ken Thompson and compositional threat modeling. We trust our tools. We trust our operating environments. (Why I use the term operating environment and not operating system is covered in my post Does That Come in a Large? OS Scale in Threat Modeling.) We either leave the operating environment out of the model entirely or treat it as implicitly out of scope. We tend to do the same with open source and third party libraries. This is a bad thing.

You would be right to argue that including the operating environment or other underlying bits would make our threat models overly complex and hard to maintain. I wouldn’t argue that point. Instead I would argue for treating them as a composition. Do the work to establish why you believe that you can trust them. Then and only then can you safely call them out of scope and move on to working at a highly level of abstraction. That’s the beauty of CTM. Any given threat model is applied only to protect its element. Once you’ve done that, you can compose the elements and deal with what’s shared between them. Typically, that’s not much. If I have two systems A and B and A requires authenticated source and so does B, when I connect them I have bi-directional source/destination authentication by composition. I trust the bits at a lower abstraction level because they have already been modeled and shown to be secure, not because I taken it on faith. As the Russian proverb attributed to Ronald Reagan goes, “trust, but verify.”

When we apply CTM we no longer have big bang threat models. We have manageable composable ones. From the outside the system presents a model with a single surface. That’s important because that’s what an entity interacting with it sees. We don’t see the database underlying a web-hosted site. We see a socket connected protocol. And even that view is an abstraction. It is through composition that we can consider what’s really important to the activity of threat modeling, the application of controls to places where they’re missing, but needed.

In a future post, I’ll get into more specifics as to how to apply CTM.

References

Mariana Trench image by 1840489pavan nd [https://commons.wikimedia.org/wiki/File:Mariana-trench.jpg]

Read Full Post »

Line Upon Line: Compositional Threat Modeling

Posted in Computers, Cybersercurity, threat modeling, tagged , , on 06 Jun 2021| 1 Comment »

With all the recent cyber activity, there has been a renewed interest in threat modeling. Generally speaking, this is a good thing. But what should we threat model, you ask? The answer is everything. And when do we need the threat modeling to be done? Why, yesterday, of course.

We all know that everything and yesterday are unattainable goals. Still, those of us in the threat modeling community do our best with the time and material we have to work with. Leaving aside the aspect of time for a moment, let’s look deeper into the material aspect.

When I say material, I’m referring to both the scope of the threat model and what we know about it. For the longest time organizations would play “hide the data” and call that their security solution. That might take the form of “in a secure facility,” “in a sealed box,” “using obfuscated code,” and the like. The key here is that security was a function of someone else’s moat protecting your crown jewels. Over time, we threw an ever increasing number of resources at the creation and sophistication of those moats.

The problem with moats is that unless you never need to get from inside to outside, there’s always a well-paved path to get across it. Now you say, “we’ve got that covered, we watch everything coming and going.” Now in addition to the moat, you’ve got to invest in more and more complex gatekeepers. And the problem with gatekeepers is that they create friction. Friction expresses itself as the consumption of resources. For computers, those resources are time, processing power and storage.

When we create computer-based products, there’s a desire to make them at as low a cost and as quickly as possible. Settings aside the cost aspect, let’s consider time-to-market and how it’s impacted by the aforementioned gatekeepers. Making systems work is hard enough, but once you add encryption and authentication and secure enclaves and the like, well, it gets really hard. The natural tendency is to make it work and then make it secure (if you have time left in your schedule).

So, by the time the average company engages security, one of two scenarios is in play. Scenario one: there’s a default assumption that security is someone else’s problem (moat-land). Scenario two: security can be overlaid in the remaining time and space.

The problem with the first scenario is that it’s been a flawed model since the 1980’s (probably earlier). As soon as you allow people to connect things to a greater world, someone is going to connect them in way that you didn’t expect. And someone is going to get over your moat. Then where will you be? Our entire history as a species is replete with stories of Trojan horse tales. Why would we imagine that the technology realm would be any different?

The problem with the second scenario is that is treats security as a feature and not an emergent property of the system. Simply put, “you can’t bolt security on.” You certainly can’t secure the complex systems we now assemble on a daily basis from an assortment of open source, third-party, and proprietary bits when you try to do so after the fact.

This certainly paints a gloomy picture for security. But what, you may ask, does this have to do with threat modeling and what is compositional threat modeling? Both good questions. Let’s get into it.

Fundamentally, threat modeling is a design activity. That is, threat modeling considers a system’s design and evaluates if sound security principles are being used. There are a myriad way to undertake this consideration. Probably the most famous being Adam Shostack‘s four questions framework. This methodology cuts to the core of threat modeling. There are any number of tools available to help automate and systematize the threat modeling process. All of them presume a fully-formed system design. Now, given that the system may have been assembled from multiple sources, you may not have that fully-formed design available. What does that mean? It means that you don’t get a complete picture of system’s design deficiencies. Now, if everyone knows this, the organization is able to make reasonable risk decisions. Many time, however, non-security individuals look at the results of a threat model and consider them the totality of possible deficiencies. This is the reality of the world.

There’s another issue with threat modeling the system in its totality after the fact. A threat model is a kind of network diagram and subject to the same kind of combinatorial explosion. This has two negative impacts. First, it’s hard to preform a systematic analysis of the model in a timely fashion when you have hundreds of interconnections to consider. Second, when deficiencies number in the thousands, the development teams and their management are unlikely to want to even look at them. They are, after all, only possible issues.

So, how can we address these diverse issues? I use a  technique that I call compositional threat modeling.

Let’s consider a really simplistic example. The following diagram shows two things communicating across a trust boundary.

I could choose to threat model this system as a whole and would need to consider the impact of both my (Thing 1) inbound data flow on me and outbound data flow on Thing 2. Alternately, I could consider only things that impacted me (consider Thing 2 out of scope). This would yield a focused set of deficiencies applying only to Thing 1. I could then perform a complementary analysis with the focus on Thing 2. Now I have a pair that I can say form a fully modeled system by composition.

The advantages to this approach are numerous. The deficiencies identified are highly focused, so teams will be more likely to consider them. The methodology scales well. The threat models are more light weight (easier to maintain). The threat modeling process can more readily accommodate a diversity of element sources and different timelines of inclusion or availability. Threat models can be created and shared in ways that do not expose organizational IP. The threat models are easier to navigate (multiple resolution views are a natural consequence).

References:

Rock strata image by Matt Affolter (QFL247), CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=14715935

Read Full Post »

Even Remotely: Teaching Threat Modeling During a Pandemic

Posted in Computers, Cybersercurity, Education, threat modeling, tagged , , on 23 Aug 2020| Leave a Comment »

Last week (17-21 August 2020) I had the pleasure of being staffing (trainer/facilitator) the first joint MDIC / FDA / MITRE Medical Device Cybersecurity Threat Modeling Bootcamp. The mind behind the training material was Adam Shostack. Originally planned as an in-person training, the pandemic forced a shift to on-line delivery.

The objectives of the bootcamp (from the MDIC site):

  • Intensive, hands-on sessions on threat modeling.
  • Learn about structured, systematic and comprehensive approach to threat modeling for engineering more secure systems from SMEs from public and private sector.
  • Learn the latest updates on medical device cybersecurity and related areas from representatives of FDA and industry.
  • Networking opportunity with SMEs from MedTech and non-MedTech sectors to learn on cybersecurity best practices that can be incorporated into the medical device industry
  • Contribute to the discussions on the development of Medical Device Threat Modeling Playbook

For anyone not familiar with Adam’s threat modeling training methodology, it is a highly interactive, small group focused training. When the training staff got together for three days in Washington, D.C. in February of 2020, this was the way we pre-flighted the bootcamp. To his credit, Adam deconstructed the material and re-envisioned it for a remote audience.

This first bootcamp had about sixty participants from across the medical device industry and include manufacturers, HDOs and regulators. The training provided a good introduction to the concepts of threat modeling and encouraged an appreciation of the needs of development, security, management and regulators. Instead the typical classroom style presentation followed by table-based group interactions, we had topic-based videos which the participants viewed in a dedicated on-line learning system, individual assignments, entire bootcamp presentations and group working sessions .

As an outcome of this bootcamp was to assist in the creation of a “playbook” for medical device threat modeling, the entire procedure was shadowed by members of the working group responsible for that effort.

So, what was my take-away as a trainer and practitioner?

Providing live distance learning is hard. The dynamic is completely different from in-person training. I’ve been taking remote live distance training classes since the proto-Coursera Machine Learning and Database classes from Stanford, nearly a decade ago. As a learner, the ability to stop the video and take notes and go back over things was invaluable. The lack of interactivity with the instructor was a drawback. This was my first experience on the other side of the screen. As a trainer and facilitator, keeping remote participants on-topic and on-schedule was challenging. Having the ability to use multiple computers (one for interaction [43″ 4K display] and another for staff side-channel discussion) was invaluable. In an in-person setting, I’d’ve had to leave the group or try and flag down another staff member, distracting from the flow.

Observationally, I think the dynamic of the participants is a bit diminished. Typically, you’d have breaks, during which participants would exchange ideas and make connections. At the end of the day, groups would have dinner together and discuss what they’re learned in greater detail.

I believe that, overall, the training was successful. My group indicated that they’d come away with a better understanding of threat modeling and a greater appreciation of the context in which the activity exists. We have another session coming up and I’m sure that it will incorporate all the lessons learned from this one. I’m looking forward to it.

The training is focused on threat modeling generally and so those not in the medical device industry would also profit from it. If you’re interested, I recommend that you visit the MDIC site linked above.

Read Full Post »

Does That Come in a Large? OS Scale in Threat Modeling

Posted in Computers, Cybersercurity, Software Development, threat modeling, tagged , , , , , on 17 Sep 2019| 2 Comments »

One of the common misconceptions I encounter when explaining threat modeling to people is the is of operating system scale. This is one of those cases where size really does matter.

When threat modeling, there is a desire to do as little work as possible. By that I mean that you shouldn’t model the same thing multiple times. Model it once put it in a box and move on. It’s furniture.

We do this to allow us to focus on the stuff we’re developing and not third-party or open source bits.

When it comes to operating systems, however, I don’t have just one border to deal with as I would with say a vendor provided driver. The thing we casually refer to as an operating system is actually a many layered beast and should be treated as such. When we do, the issue of OS scale disappears in a puff of abstraction smoke.

So, what is this so far unexplained scale?

Let’s rewind a bit to the original computers. They were slow, small (computationally and with respect to storage) and, in the grand scheme of things, pretty simple. There was no operating system. The computer executed a single program. The program was responsible for all operational aspects of its existence.

As computers became more sophisticated, libraries were created to provide standardized components, allowing developers to focus on the core application and not the plumbing. Two of these libraries stand out: the mass storage and communications libraries. We would eventually refer to these as the file system and network.

When computers began expanding their scope and user base, the need for a mechanism to handle first sequential, then later multiple jobs led to the development of a scheduling, queueing and general task management suite.

By the time Unix was introduced, this task manager was surrounded by access management, program development tools, general utilities and games. Because, well, games.

For users of these systems, the OS became shorthand for “stuff we didn’t need to write.”

The odd thing is that, on the periphery, there existed a class of systems too small or too specialized to use of even require this on-stop-shopping OS. These were the embedded systems. For decades, these purpose-built computers ran one program. They included everything from thermostats to digital thermometers. (And yes, those Casio watches with the calculator built in.)

Over time, processors got a lot more powerful and a lot smaller. The combination of which made it possible to run those previously resource hungry desktop class operating systems in a little tiny box.

But what happens when you want to optimize for power and space? You strip the operating systems down to their base elements and only use the ones you need.

This is where our OS sizing comes from.

I like to broadly divide operating systems into four classes:

  • bare metal
  • static library
  • RTOS
  • desktop / server

Each of these presents unique issues when threat modeling. Let’s look at each in turn.

Bare Metal

Probably the easiest OS level to threat model is bare metal. Since there’s nothing from third-party sources, Development teams should be able to easily investigate and explain how potential threats are managed.

Static Library

I consider this the most difficult level. Typically, the OS vendor provides sources which development builds into their system. Questions of OS library modification, testing specific to target / tool chain combination, and threat model (OS) arise. The boundaries can become really muddy. One nice thing is that the only OS elements are the ones explicitly included. Additionally, you can typically exclude aspects of the libraries you don’t use. Doing so, however, breaks the de-risking boundary as the OS vendor probably didn’t test your pared down version.

RTOS

An RTOS tends to be an easier level than a desktop / server one. This is because the OS has been stripped down and tuned for performance and space. As such, bits which would otherwise be laying about for an attacker to leverage are out of play. This OS type may present issues in modeling as unique behaviors may present themselves.

Desktop / Server

This is the convention center of operating systems. Anything and everything that anyone has ever used or asked for may be, and probably is, available. This is generally a bad thing. On the upside, this level tends to provide sophisticated access control mechanisms. On the downside, meshing said mechanisms with other peoples’ systems isn’t always straightforward. In the area of configuration, as this is provided by the OS vendor, it’s pretty safe to assume that any configuration-driven custom version is tested by the vendor.

OS and Threat Modeling

When threat modeling, I take the approach of treating the OS as a collection of services. Doing so, the issue of OS level goes away. I can visually decompose the system into logical data flows into process, file system and network services; rather than a generic OS object. It also lets me put OS-provided drivers on the periphery, more closely modeling the physicality of the system.

It’s important to note that this approach requires that I create multiple threat model diagrams representing various levels of data abstraction. Generally speaking, the OS is only present at the lowest level. As we move up the abstraction tree, the OS goes away and only the data flow between the entities and resources which the OS was intermediating will be present.

Let’s consider an application communicating via a custom protocol. At the lowest level, the network manages TCP/UDP traffic. We need to ensure that these are handled properly as the transit the OS network service. At the next level we have the management of the custom protocol itself. In order to model this properly, we need for the network service to not be involved in the discussions. Finally, at the software level, we consider how the payload is managed (let’s presume that it’s a command protocol).

Nowhere in the above example does the OS level have any impact on how the system would be modeled. By decomposing the OS into services and treating layers uniformly, we gain the ability to treat any OS like furniture. It’s there, but once you’ve established that it behaves properly, you move on.

Read Full Post »

The Future is (Azure) Sphere

Posted in Apple, Computers, Cybersercurity, Future, Microsoft, Software Development, tagged , , , , , , , , on 04 May 2019| Leave a Comment »

There have been numerous times when a new technology has led to a major shift in how we thought about how computers and software should be built. We are about to see one of those shifts. At least that’s what I’ve come to believe.

Let’s pop into the Wayback and set our sights on the early ’80s. At that time computers had one processor. Hardware-based floating point were the domain of mainframes and minicomputers. Communications between computers existed only for the well-heeled. Security meant keeping your computer locked up.

Life was pretty simple. If you wanted something done, you did it yourself. When software was shared it was done via the US Postal Service on 9-track tape.

Fast forward to the early ’90s. Desktop computers were fairly common. Uniprocessors still ruled. Hardware floating point was now readily available. The internet had just been introduced. Gopher was slowly to be displaced by the combination of FTP and web search engines. Security issues were a thing that happened, but was, on the whole a black art practiced by a small number of individuals and required skills that you needed to develop yourself.

It was around this time that I was casting about for a thesis topic for my Master’s in Electrical and Computer Engineering. I took on the topic of virus-resistant computer architectures (AARDVARK). Did I mention that it was 1992? Just researching the state of the art in computer viruses was a huge task. No Google, Amazon or ACM online article search. As to the other side of the equation, the how and why of hacking, well, I’ll leave that for another time.

By the time I was done, I’d proposed a computer architecture with separate instruction and data spaces where the application’s binary was encrypted and the key loaded in a separate boot sequence was stored in a secure enclave, accessible only to the binary segment loader. Programs were validated at runtime. I conjectured that such a computer would be ideal for secure use and could be built within the 18 months.

Everyone thought it was a great design and the school even worked with me to apply for a patent. The US Patent Office at that time didn’t get it. After five years we abandoned the effort. I was disappointed, but didn’t lose sleep over it.

Fast forward to 2012 when Apple released the iOS 6 security guidelines. Imagine my amusement when I see echos of AARDVARK. It’s all there: signed binaries, secure enclave, load validation. Good on them for doing it right.

Let’s step back and consider the situation. Computers are really small. They have integrated hardware floating point units, multi-processors and now, with the advent of this generation of iPhone, hardware-based security. The internet has gone global. Google indexes everything, Open source is a thing. So, we’re good?

Not so much. The Apple iPhones are an oasis in a vast desert of security badness. Yes, IPv6 has security goodness available, but IPv4 still rules. Secure programming practices are all but non-existent. Scan and contain is the IT mantra. Threat modeling is an exercise for the academic.

This brings to last year. Microsoft announced Azure Sphere. Application processor, dual-MCU, networking processor, security processor. All firewalled. All in the same package. The provided OS was a secured version of Linux. Each device is registered so only the manufacturer can deploy software, push updates and collect telemetry via the Azure cloud.

There must be a catch. Well, as you know, there’s no such thing as a free burrito.

The first device created to the Azure Sphere specification is the Mediatek MT3620. And no, you can’t use it for your next laptop. The target is IoT. But, there’s a lot of horsepower in there. And there’s a lot of security and communications architecture that developers won’t have to build themselves.

Microsoft is touting this a the first generation. Since they started with Linux and ARM, why wouldn’t you want to get something with more power for systems that have security at their core. If Microsoft approached this as Apple has the iPhone, iPad, AppleTV and Apple Watch; why shouldn’t we expect consumer computers that aren’t insecure.

But will I be able to use them for software development? That’s a tricky question.

When I envisioned AARDVARK, my answer was no. That architecture was designed for end-user systems like banks and the military. You can debug a Sphere device from within Visual Studio, so, maybe it’s doable. You’d need to address the issue of a non-isomorphic ownership model.

Are users willing to bind their device to a single entity? Before you say no, consider how much we’re already put in the hands of the Googles and Facebooks of the world. Like it or not, those are platforms. As are all the gaming systems.

Regardless, I believe that we will end up with consumer compute devices based on this architecture. Until then we’ll just have to watch to see whether the IoT sector gets it and by extension the big boys.

Either way, the future is Sphere.

Read Full Post »

2018 My Year in Numbers

Posted in Computers, General, Software Development, tagged , , , on 13 Jan 2019| Leave a Comment »

Like many people working in technology, every year I assemble a summary of accomplishments for my annual review. It’s always interesting to take a long view look at things. This is especially true when you’re working on things with long lifetimes and uncertain outcomes.

Let’s look at the raw numbers:

  • 73 topics researched
  • 1 intern supervised / mentored
  • 11 independent projects led
  • 2 classes created
  • 3 classes updated
  • 8 classes taught
  • 61 student taught
  • 6 books reviewed for possible internal use
  • 2 standards bodies participated in
  • 1 ISO technical study group chaired
  • 18 project teams worked with
  • 12 first-line managers worked with
  • 4 upper-level managers worked with
  • multiple outside organizations worked with
  • 126 individual code reviews participated in
  • 29 internal trainings taken
  • 2 conferences attended
  • 2 Coursera classes taken

How can I be sure about these numbers? In a word, notebooks. I’m old school that way. It’s not that I don’t use technology for notes. I use Microsoft OneNote to track various subjects and lines of thought. URLs don’t really work in notebooks (or notes to Santa). But for daily tracking of thoughts and events, being able to pick up a pen and start writing is unequaled for me. I take my notebook to meetings preferentially. They don’t get IMs in the middle of meetings.

From these notebooks come my weekly status summaries. From those come my annual status summary document. If anything, my numbers may be a little low. There are times when I neglect to write in my notebooks.

2018 was a very busy year. Lots of overlapping projects in flight. Many of which produced their first fruits. Most of them were multiple years in planning and execution, requiring the efforts across many teams. I love it when a plan comes together. I had the opportunity to work with a cosmic boat load of teams.

It’s a pleasure for me to be asked to create and teach classes. I learn more about the subjects. I get to help improve other peoples’ skills.

Participating in conversations with the ISO C / C++ committees is always an education for me. It doesn’t matter how long I worked with a programming language, there’s something to learn, some new view or example that will help me teach others. It fun.

Participating in code review is much along the same lines. It’s a discussion with the code and the developer. Done properly, everyone learns something. And through the process, you get better code.

I read a lot, but usually that’s a person endeavor. Reading technical books for possible use by others within my organization either for general reference of in conjunction with a class is a different kind of reading. The scope, presumed background and audience are all very different from me just adding another chunk into my existing world map. I need books in support of individuals who need current reference materials. Sometimes I need them in support of technology which is vastly out of date.

One thing I don’t track are all the non-dead tree reference materials I review, summarize and pass along in support of the research projects or management requests for information that I do on a daily basis. On one level, this is a hole in my somewhat obsessive self tracking. On the other, doing so would be too much of an interruption to flow. This material, at least the good stuff, get tracked by subject in OneNote. Eventually, it’s either folded into supporting material summaries for management or put at the end of class material sections of for support and further reading.

Some of my most interesting work last year revolved around interactions with outside organization. Bringing technologies in to lighten the load and support group efforts is always satisfying.

As to what 2019 will be like, who can say. If it’s anything like 2018 was, there will be a lot to write about in next year’s review post.

image credit: Dustin Liebenow (creative commons)

 

Read Full Post »

No Magic: Security and Understanding the Source

Posted in Computers, Cybersercurity, Software Development, tagged , , on 24 Dec 2018| Leave a Comment »

When I was an undergraduate, I heard a story about a DEC PDP 11/70 at a nearby school that had a strange hardware mod. A toggle switch had been added by someone and wired into the backplane apparently. The switch had two settings, “magic” and “more magic.” The identity of the individual or individuals having made the mod was lost. For as long as anyone could remember, the switch had been in the “magic” position. One day, some brave soul decided to find out what happened when the “more magic” setting was selected. Upon flipping the toggle, the machine crashed. It thereafter resisted any attempts to get it to run. After a bit, they gave up, flipped the toggle back to “magic“, power cycled the machine and hoped. The machine returned to its previous state of operational happiness. One could say that they’d been trying to achieve too much of a good thing.

We might read this and come away with the idea that, well, they just should have gotten on with their work and not worried about the plumbing. That’s certainly the majority view, from what I’ve seen. But why was the switch there in the first place? If it only worked in one position, shouldn’t they have just wired things without the switch?

Let’s consider the temporal aspect, no one remembered who, when, or why, let alone what. It may well have been the case that once “more magic” actually worked. Who can say. That whole documentation thing.

When I work with project teams and individual developers, I have a habit of saying “no magic.” It comes from having heard this story. I’ll say this when working with individuals who’s code I’m reviewing, teams who’s architecture I’m reviewing, or leads and architects while facilitating the creation of threat models. I don’t care whether the magic manifests as constants (magic numbers) from who-knows-where or logic that’s more convoluted than a Gordian Knot. Basically, if the reason that something is being used exists without the benefit of understanding, it shouldn’t be there. I don’t care who put it there or how smart they were. Someday someone is going to come along and try to change things and it will all go south. Enough of these in a code review and it’s likely to get a single summary review comment of “no.”

How does this relate to security? Do you know what the auto-completion for “never implement your” is? I’ll let you try that on you own, just to verify. Never implement your own crypto[graphic functions]. Why? Where should I start? The math is torturous. The implementation is damn hard to do right. Did you know that you can break poorly implement crypto via timing analysis? Even if you don’t roll your own crypto, are you using some open source library or the one from the operating system? Do you know when to use which? Are you storing your keys properly?

Magic, all of it.

Some people believe that security can be achieved by obscuring things. These also tend to be the same people who’ve never used a decompiler. You’d be amazed what can be achieved with “a lot of tape and a little patience.”

If your goal is to have software and systems that are secure, you can’t have magic. Ever.

So, when I see company with a core philosophy of “move fast, break things,” I think well aren’t they going to have more attack surface than a two pound chunk of activated carbon. Not amazingly, they did and we are worse off because of it.

You can’t secure software-based systems unless you understand how the pieces play together. You can’t understand how the pieces play together until you understand how each piece behaves. You can’t understand how a piece behaves if it’s got magic floating around in it. It’s also important to not just glom onto a technique or technology because it’s handy or trendy. As Brian Kernighan and P.J. Plauger said, “it is dangerous to believe that blind application of any particular technique will lead to good programs[2].”

While you’re out there moving fast and tossing things over the wall, keep in mind that someone else, moving equally fast, is stitching them together with other bits. The result of which will also be tossed over another wall. And while it is true that some combination of these bits product interesting and quite useful results, what is the totality of their impact? At what point are we simply trusting that the pieces we’re using are not only correct and appropriate to our use, but don’t have any unintended consequences when combined in the way we have done.

You need to know that every part does the thing you intend it to do. That it does it correctly. And that, it does nothing you don’t intend. Otherwise, you’re going to have problems.

I’ll close with another story. In the dim days, before people could use the Internet (big I), there were a number of networks. These were eventually interconnected hence the name interconnected networks or Internet for short. Anyway, back in the day (early ’80s), universities were attaching to the Internet backbone, which was in and of itself pretty normal. What was not normal was when someone accidentally mounted a chunk of the Andrews File System (AFS) onto an Internet node. It ended up mounting the entirety of AFS on the Internet. This had the unexpected side effect of making a vast number of students previously unprotected emails publicly available to anyone with Internet access. Mostly that meant other university students. AFS wasn’t actually designed to be connected to anything else at that time. Bit of a scandal.

Unintended consequences.

  1. Image credit: Magic Book By Colgreyis ©Creative Commons Attribution 3.0 License.
  2. Kernighan and Plauger, Software Tools, 1976, page 2 paragraph 4

Read Full Post »

Ignoring Threats: Flaws vs. Bugs

Posted in Computers, Cybersercurity, security, Software Development, tagged , , , on 17 Dec 2018| Leave a Comment »

When creating a class, it’s important to have a motivating example. In my experience, people learn best when they can see an immediate application to their own work. In the area of cybersecurity, this can be difficult. Examples in this space tend to be either too esoteric (return-oriented programming) or too divorced from the domain (credit card theft).

I’ve just finished up the creation of a two hour software security fundamentals class for management and developers. This is intended to provide a framework for integrating security into the software development process. Build it in vs. bolt it on. As I was putting the class together, the motivating example was just out of reach.

The push-back that must be overcome is that there already exists a process for dealing with security issues. It’s an extension to the standard quality assurance process. This process merely needs to be extended to include security-related testing, right?

Let’s look at that assertion for a moment.

How exactly does quality assurance work? Well, it’s based, by and large, on the flawed hypothesis model. Starting with the documentation, test cases are created to verify the assertions made therein. From there, scenarios are imagined. These are likewise verified. If issues (bugs) are discovered, generalizations are attempted. Any found point to larger problems in the code.

Sounds good, what’s the problem?

Consider the internet joke:

QA engineer walks into a bar. They order a beer, then order 0 beers, then order 999999999 beers, then orders a lizard, then orders -1 beers, then orders a eawlirensadk.

A customer walks into the bar and asks where the bathroom is. The bar bursts into flames, killing everyone.

That’s pretty much the problem with the flawed hypothesis model. You only verify the things you think of. If you’re only looking at how the bar serves beer, you’ll never catch issues involving other aspects of the system (here, bathroom location).

It’s a bit extreme as a motivating example, but everyone can relate to it, which is, of course, the point.

From there, the concept of flaws vs. bugs can emerge. QA finds bugs. On a good day, these may point to flaws. So, what’s the difference. For the purposes of discussion, flaws are design defects and bugs are implementation (code) defects. By its very nature, QA does not test design, only implementation.

At this point, management asks the question, isn’t this how it’s always been? Generally speaking, yes. Long gone are the days when people used program design language (PDL) to reason about the soundness of their software. At that time, security wasn’t much of a focus.

Enter threat modeling. By its very nature, threat modeling allows us to reason on the design. Why? Because it focuses not on the documentation, but rather the data flows and through extension the work flows of the system. Because we abstract ourselves from the implementation, we can reason about the system in ways that point us directly to security flaws.

To relate the impact to the real world, one has only to look at the cost to Samsung of not catching a design flaw in the Note 7 prior to release (US$17B). IBM estimates that relative to catching an issue a the design stage that the cost is 6.5 time higher in the implementation stage, 15 time higher during testing, and 100 times higher after release.

I’m in no way advocating the elimination of QA testing. You need both. As well as the processes we do in between, such as code reviews and static / dynamic analysis. But again, discovering issues in these stages of development is going to be more expensive. Defense-in-depth will always give you a better result. This is true not only in security, but the development process itself.

As I was finishing up my software security fundamentals class, the news broke regarding a high-profile technology firm that exposed the private data (images) of millions of individuals via their developer APIs. This is probably a case of failing to threat model their system. This isn’t the first time that this particular company has failed miserably in the area of security. It points out, in ways which greatly assist my efforts to get management on-board, that the failed hypothesis model is no substitute for critical analysis of the design itself.

As a system grows in complexity, it is critical to abstract out the minutiae and let the data flows point toward possible issues in the design. Threat modeling is one technique, but not the only one, that makes that possible.

Read Full Post »

Older Posts »