OWASP Feedback: Does Embedded = Secure?
I recently briefed the OWASP forum in NYC, and I received some great feedback that I'd like to address en mass. First, my thanks to all of you who attended - it's a great organization that I hope to become more involved with. Second, thank you for all the kind words and positive comments. It's clear we all had some fun with my topic, and that many of you felt you learned a bit as well, which I really appreciated hearing. (Download slides.)
On to business. The most interesting feedback revolved around two questions: 1) For years I have been saying that embedded systems can be more secure, now I am saying they aren't - which is it? 2) You understood that HYDRA was very secure, but wanted to know specifically how that security helped applications which HYDRA protected.
Both are great questions, and both meant you were really listening, which I truly appreciate. But they also mean that my attempt to fit so much into so little time was not wholly successful with the entire audience. Let's address these now in detail then, one a time:
Embedded systems can be made more secure in part because they tend to be smaller in both code size and complexity, and therefore are often more completely testable. While size and complexity are not the largest factors in the security equation, all else being equal they can be the deciding factors.
Remember those posters of the Linux kernel that were wildly popular for a while? I saw one that filled a wall in a meeting room with it's many thousands of bubbles and connections. In contrast, I've worked on systems for which I could sketch the 50-odd bubbles of the data flow diagrams from memory at the cafeteria table. Of course, those systems were not nearly as flexible as Linux, but they did their job with a level of robustness and performance that is impractical for Linux or other GPOSs to achieve.
It's not a question of better, it's a question of what you need for your specific project. Linux should not be in the flight controllers of fighter jets anytime soon, but µC/OS isn't exactly going to power a million-dollar-a-day e-commerce system any time sooner.
Imagine, if you will, the task of security testing each component and module and subsystem in a general-purpose OS the size of Linux, or even Windows. If you're not put off yet, remember you must repeat the process for each possible interaction. After all, two secure components put together can create a weakness just in their interaction. Even small systems quickly tend towards being impractical to completely test, let alone something the of the size magnitude of Windows.
The fact is that the extent to which you can test a system's security is inversely proportional to (among other things) the number and complexity of the capabilities of the system, and the assumptions about input to and usage of the system. A more testable system, however, does not mean that system has been more tested. "Testable" ≠ "tested."
In recent times, I've noticed too many developers ignoring that fact, and taking all those "in general" and "tend to be" statements to heart by not exercising the same rigor they would with non-embedded development. The same can be said of users, who seem to have started assuming that any embedded system they use is both robust and secure. So I offered some entertaining war stories (my personal favorite is Niall Murphy's microscope example) to get us back on track.
Many vendors are taking advantage of the embedded myth by removing the monitors and keyboards from their servers, then calling them an embedded system. "Headless" ≠ "embedded". So one part of my agenda here is to create a healthy skepticism in customers of such systems. In the end, that's good for both vendors and their customers.
Here is one last way to think of this. I like to follow the old adage of being as simple as possible, so my tactics are as follows: use simple language and examples to describe my position. 90% of people will understand, and since I don't make this stuff up, only a slightly smaller percentage will usually find themselves in agreement. Since you're still reading, I'm going to assume you are either sufficiently entertained or sufficiently confused. Let me make either case worse by offering up some math notation.
Say you have a security posture target of s. If the security posture of an embedded system is Se and that of a general-purpose system Sg, we can safely say that for most systems:
Although I didn't want to turn my briefing into a sales presentation, I clearly left many of you with a thirst for more information on HYDRA. Recall that I cited HYDRA as a good example of an enterprise-scale embedded system that looked like it may be running BSD or Linux, but isn't.
As I mentioned, HYDRA is indeed a hard real-time embedded device that takes in HTTP and HTTPS requests from clients, applies a security policy, then proxies a wholly new request to the server. HYDRA is designed as a reverse-proxy to protect servers from attacks at Layer 3 up to Layer 7 (i.e. everything from SYN floods to SQL injections). There is a great deal more information at the Sentinel Security Corporation Web site.
We designed HYDRA with an RTOS for three reasons: 1) for the real-time performance requirement given that we are such a CPU-intensive application, 2) to introduce diversity between the target system and the policy enforcement engine, and 3) because we needed to minimize the variables, such as an OS or other applications, in our security equation.
In the end what you have is a device that is provably very robust against attacks, and certainly that comes into play when you think about the fact that it is policing the traffic to the server. After all, if your IDS/IPS/Firewall is compromised, all bets are off.
More than that, however, is the addition of the Medusa application security layer. Medusa is the subsystem which looks for a myriad of attacks, and blocks or sterilizes the request according to the established security policy. And since HYDRA rewrites requests rather than forwarding packets, in many cases an attack is subverted because you need to get HYDRA to rewrite the way you want it to, as opposed to designing and launching the attack directly. This alone is problematic for an attacker.
So take a look at the Sentinel Security Corporation Web site, and feel free to contact me with any questions, and I can direct your inquiry appropriately.
Before I close, whenever I mention Linux or OS X I like to remind you that I have an open mind that loves to learn from your opinions and experiences. I find Linux and OS X users are often good at finding insult with anything I write concerning either OS, and as a user and supporter of both, I promise that I have no such intent.
Once again, thank you for all your kind words. You can always contact me with comments about this and other posts.
On to business. The most interesting feedback revolved around two questions: 1) For years I have been saying that embedded systems can be more secure, now I am saying they aren't - which is it? 2) You understood that HYDRA was very secure, but wanted to know specifically how that security helped applications which HYDRA protected.
Both are great questions, and both meant you were really listening, which I truly appreciate. But they also mean that my attempt to fit so much into so little time was not wholly successful with the entire audience. Let's address these now in detail then, one a time:
1) Embedded = or ≠ Secure, which is it?
It's neither. Being an embedded system does not make you more or less secure than a system that uses a general-purpose operating system, and that's the big take-away here. What I've been saying all these years is that embedded systems can often be made more secure than their general-purpose counterparts. But "can be" ≠ "is".Embedded systems can be made more secure in part because they tend to be smaller in both code size and complexity, and therefore are often more completely testable. While size and complexity are not the largest factors in the security equation, all else being equal they can be the deciding factors.
Remember those posters of the Linux kernel that were wildly popular for a while? I saw one that filled a wall in a meeting room with it's many thousands of bubbles and connections. In contrast, I've worked on systems for which I could sketch the 50-odd bubbles of the data flow diagrams from memory at the cafeteria table. Of course, those systems were not nearly as flexible as Linux, but they did their job with a level of robustness and performance that is impractical for Linux or other GPOSs to achieve.
It's not a question of better, it's a question of what you need for your specific project. Linux should not be in the flight controllers of fighter jets anytime soon, but µC/OS isn't exactly going to power a million-dollar-a-day e-commerce system any time sooner.
Imagine, if you will, the task of security testing each component and module and subsystem in a general-purpose OS the size of Linux, or even Windows. If you're not put off yet, remember you must repeat the process for each possible interaction. After all, two secure components put together can create a weakness just in their interaction. Even small systems quickly tend towards being impractical to completely test, let alone something the of the size magnitude of Windows.
The fact is that the extent to which you can test a system's security is inversely proportional to (among other things) the number and complexity of the capabilities of the system, and the assumptions about input to and usage of the system. A more testable system, however, does not mean that system has been more tested. "Testable" ≠ "tested."
In recent times, I've noticed too many developers ignoring that fact, and taking all those "in general" and "tend to be" statements to heart by not exercising the same rigor they would with non-embedded development. The same can be said of users, who seem to have started assuming that any embedded system they use is both robust and secure. So I offered some entertaining war stories (my personal favorite is Niall Murphy's microscope example) to get us back on track.
Many vendors are taking advantage of the embedded myth by removing the monitors and keyboards from their servers, then calling them an embedded system. "Headless" ≠ "embedded". So one part of my agenda here is to create a healthy skepticism in customers of such systems. In the end, that's good for both vendors and their customers.
Here is one last way to think of this. I like to follow the old adage of being as simple as possible, so my tactics are as follows: use simple language and examples to describe my position. 90% of people will understand, and since I don't make this stuff up, only a slightly smaller percentage will usually find themselves in agreement. Since you're still reading, I'm going to assume you are either sufficiently entertained or sufficiently confused. Let me make either case worse by offering up some math notation.
Say you have a security posture target of s. If the security posture of an embedded system is Se and that of a general-purpose system Sg, we can safely say that for most systems:
Meaning that the probability of achieving the security posture in either system is about the same. Now lets apply some rigorous testing and review functions r() to both systems. In that case:
Still no great differences. But what if we now add some mental cycles to working out (or removing) the assumptions A that we have about an embedded system, as I suggest doing in A Framework for Considering Security in Embedded Systems. Now we have:
Meaning that we get more bang for the buck out of our work towards security in the smaller, simpler system with limited functionality and no assumptions about usage than we will out of the larger complex system that was designed without limits or assumptions, but is equally as well tested.
Having now explained that position in every way I can think of, allow me to move on.
2) How is HYDRA's security posture transferred to the servers it protects?
Although I didn't want to turn my briefing into a sales presentation, I clearly left many of you with a thirst for more information on HYDRA. Recall that I cited HYDRA as a good example of an enterprise-scale embedded system that looked like it may be running BSD or Linux, but isn't.
As I mentioned, HYDRA is indeed a hard real-time embedded device that takes in HTTP and HTTPS requests from clients, applies a security policy, then proxies a wholly new request to the server. HYDRA is designed as a reverse-proxy to protect servers from attacks at Layer 3 up to Layer 7 (i.e. everything from SYN floods to SQL injections). There is a great deal more information at the Sentinel Security Corporation Web site.
We designed HYDRA with an RTOS for three reasons: 1) for the real-time performance requirement given that we are such a CPU-intensive application, 2) to introduce diversity between the target system and the policy enforcement engine, and 3) because we needed to minimize the variables, such as an OS or other applications, in our security equation.
In the end what you have is a device that is provably very robust against attacks, and certainly that comes into play when you think about the fact that it is policing the traffic to the server. After all, if your IDS/IPS/Firewall is compromised, all bets are off.
More than that, however, is the addition of the Medusa application security layer. Medusa is the subsystem which looks for a myriad of attacks, and blocks or sterilizes the request according to the established security policy. And since HYDRA rewrites requests rather than forwarding packets, in many cases an attack is subverted because you need to get HYDRA to rewrite the way you want it to, as opposed to designing and launching the attack directly. This alone is problematic for an attacker.
So take a look at the Sentinel Security Corporation Web site, and feel free to contact me with any questions, and I can direct your inquiry appropriately.
Before I close, whenever I mention Linux or OS X I like to remind you that I have an open mind that loves to learn from your opinions and experiences. I find Linux and OS X users are often good at finding insult with anything I write concerning either OS, and as a user and supporter of both, I promise that I have no such intent.
Once again, thank you for all your kind words. You can always contact me with comments about this and other posts.
