Using Ruby In Security Critical Applications

by Tom Macklin

The video titled "Using Ruby In Security Critical Applications" by Tom Macklin, presented at RubyConf 2015, delves into the various security measures taken to enhance the Ruby programming language for applications that require high security. Macklin draws from his experiences at the US Naval Research Laboratory and emphasizes the importance of simplicity and effective architectural design in programming and security.

Key points discussed include:
- Understanding 'Security Critical': Macklin opens by clarifying the term "security critical" and sharing his insights from past experiences, stressing that security cannot be guaranteed solely through assurances but instead requires meaningful evidence and effective architecture.
- Assurance Principles (NEAT): He introduces the NEAT principles—Non-bypassable, Evaluatable, Always invoked, and Tamper-evident—highlighting their importance in establishing robust security frameworks throughout the system's architecture.
- Security Controls: Emphasizing layers of security, Macklin discusses how integrating the right security controls at appropriate layers is crucial. He advises on utilizing operating system controls that prevent unauthorized access to sensitive data and systems.
- Use Case Examples: Macklin offers a composite use case to demonstrate security principles in action, showing that secure system architecture can significantly reduce vulnerabilities by adopting simpler design principles.
- Community Engagement for Security Enhancements: The speaker also shares initiatives aimed at improving Ruby’s security and invites community involvement to bolster these efforts.
- Integration and Isolation: He discusses the significance of isolating processes within services and emphasizes enterprise integration as a vital aspect to maintain security, particularly with regard to communication protocols and database access.
- Future Aspirations: Towards the conclusion, Macklin highlights future objectives that include automating security rule sets, employing monads for validation, and exploring tools that can enhance security measures in Ruby applications.

Overall, Macklin's presentation emphasizes that thorough architectural thinking, community collaboration, and systematic security measures can enhance Ruby’s applications in environments where security is paramount. His insights encourage developers to adopt a methodical approach to security while fostering collaboration within the Ruby community to tackle security challenges collectively.

00:00:15.200 All right, well, uh, welcome everybody to my talk. Thanks for coming. I hope everyone's having a good conference; I know I am. Is everybody learning a lot?

00:00:22.400 Excellent! I try to leave a few minutes when I do talks because I learn so much in conferences, and I want to talk about the stuff I'm learning in other people's talks more than what I came to talk about.

00:00:34.760 So if I get on a side note about something that I heard, the last talk I was at was phenomenal. But anyway, I hope you all get a lot out of my talk today.

00:00:41.800 Before I say anything else, let me get this disclaimer out of the way: I work for the US Naval Research Laboratory, but my talk today reflects my opinions based on both my professional and personal experiences.

00:00:48.520 My opinions do not represent those of the US Navy or the US government. As a matter of fact, if you do any research, you'll probably find that there are a lot of people in the government who disagree with me on many things.

00:01:00.680 Also, another disclaimer: I tend to say 'we' a lot when I talk because I have a really close-knit team, and it's an awesome team. We argue about stuff and don't always agree, but when I say 'we,' I'm not referring to big brother or all the developers I work with.

00:01:14.040 I'm subconsciously referring to the fact that we try to make as many decisions as we can as a team.

00:01:19.280 So, I apologize in advance when I say 'we.' Now, a little bit about me: I consider myself a good programmer, not a great one, but I like to keep things simple.

00:01:26.600 I study a martial art called Aido, and in Aido, we have a saying: an advanced technique is just a simple technique done better. I like to apply that, not just in martial arts but in all aspects of my life, and programming is no exception.

00:01:40.159 Everything I do and talk about has the underlying theme: keep things as simple as you possibly can.

00:01:46.040 Regarding the Naval Research Laboratory, it was started in 1923 by Congress on the recommendation of Thomas Edison, who believed we needed a naval research lab. The group I work in, the Systems Group, has come up with some cool technology.

00:02:04.799 Most notably, the onion router (Tor) came out of NRL, along with foundational technologies for virtual private networking.

00:02:09.000 There’s a great paper from 1985 called "Reasoning About Security Models," written by Dr. John Mlan, who is my boss’s boss’s boss’s boss’s boss.

00:02:16.680 This paper discusses system Z, and if you're into academia, it's a really cool theory about security.

00:02:21.200 All that said, my talk is not about anything military-related; it's not academic, and it’s definitely not buzzword bingo. I had a really cool buzzword bingo slide, but I took it out because CCS was way better.

00:02:34.319 So, what am I going to talk about? I want to spend some time unpacking what I mean by 'security critical'; as we've just heard in the last talk, people throw phrases around that mean different things to different folks.

00:02:51.920 So, I want to clarify what I mean by 'security critical.' Sorry about that! I also want to work through a use case, which isn’t an actual case but rather a composite of experiences I've had.

00:03:05.599 It borrows from systems I've worked on and developed, but it's not representative of any system we've ever built. The main reason I'm here is my next point: next steps.

00:03:30.480 We have many initiatives we are interested in pursuing to enhance our ability to use Ruby in security-critical applications. Some of these initiatives we know how to do well, others we think we know how to do but probably wouldn't execute well, and others we know we can't do.

00:03:43.640 If anything you see on my next step slides resonates, please come talk to me after the talk, as we’re eager to get help from people who want to do cool stuff with security and Ruby.

00:03:54.720 There’s a great talk I attended that influenced my thinking about Ruby and security back in 2012. It was at a conference called Software Craftsmanship North America, which I highly recommend.

00:04:07.239 Uncle Bob gave a talk titled "Reasonable Expectations of a CTO"—if you haven’t seen it, look it up on Vimeo. I won’t summarize it for you, but as you watch it, just add security to the list of problems systems have.

00:04:19.000 This insight resonates even more today than when he first gave the talk in 2012. When we talk about computer security, one essential thing to discuss is assurance.

00:04:42.240 Assurance usually, as a verb, means to assure you that everything will be okay, that there’s no problem. However, when I talk about assurance, I’m not speaking about just telling you everything will be okay.

00:04:54.080 What’s the first thing you think when I tell you everything's going to be okay? You think something's wrong. So I don’t want to assure you of anything.

00:05:01.479 What I want to do is to provide you with assurances that allow you to make your own decisions.

00:05:07.120 Even if you don’t like the assurances received from a security analysis, at least you know where you stand, and that’s genuinely useful.

00:05:12.639 When I talk about assurances, I’m not trying to promise everything will be okay; I’m talking about evidence.

00:05:18.199 We've all seen this chart before, and whether you're trying to make money, make the world a better place, or solve a security problem, this chart is unavoidable.

00:05:25.440 When we go about solving a security problem, we encounter this as well. We have a few choices: we can do something clever to outsmart attackers, we could buy a cool library that promises security, or we could hire an external consultant.

00:05:39.720 However, don’t do any of that because attackers are clever—more clever than me or you. What's more, there are lots of them, and they have plenty of time.

00:05:52.280 You build a feature, then it's on to the next one; they are there hammering at your systems day after day—sometimes in teams, if you're unlucky enough to be a target. Most of you aren't, but we make mistakes in our code; it's simply a fact of life.

00:06:04.639 There will be bugs, including security bugs, so I'm going to discuss how we can defend ourselves. A key point I want to make today is that a security critical system should have the right security controls in the right places and with the right assurances.

00:06:16.319 Let's say that again: our security critical system should have the right security controls in the right places and with the right assurances.

00:06:26.800 I like to achieve this through architecture. We construct architecture, and many times, the principles that make code awesome are the same principles that make it secure.

00:06:34.479 We want to reduce complexity, localize functionality, and improve test coverage, among other goals. But we also must ensure we have the right controls in the right places.

00:06:47.440 Having a firewall at the front door won’t keep bad guys out, just as a guard with a gun in your server room isn't going to prevent hackers from accessing your server.

00:06:59.120 You need to consider the architecture of your code, your design, and your test coverage while also thinking about where and how you're using various controls. More specifically, we need to layer those controls in our systems.

00:07:19.440 Some of these acronyms may not be familiar to you; I'll explain them later, but these are the security control layers you should consider a minimum for your application.

00:07:30.560 You have your operating system, your security framework, and then your application framework. These layers serve as the foundation for our assurances.

00:07:38.599 But what are these assurances? Are they something squishy that we can’t measure? Well, kind of, but we can discuss them in a semi-structured way.

00:07:44.319 I like to talk about assurances in terms of this neat principle. NEAT stands for Non-bypassable, Evaluatable, Always invoked, and Tamper-evident.

00:07:56.680 The more you can measure your security controls and affirmatively answer these questions by nodding instead of shaking your head, the more security you will have.

00:08:03.879 Let’s go through these quickly. Non-bypassable: if you've got a circuit breaker, it prevents your electronics from frying due to an excess current.

00:08:09.400 It will trip the breaker to stop the current flow, but if there's a wire going around the circuit breaker, linking the power directly to your device, it won't help.

00:08:14.479 For a good control to work, it has to be the sole pathway from point A to B.

00:08:21.240 Evaluatable is a little harder to articulate. There are tools like symbolic execution engines and static analysis tools to measure and assess code security.

00:08:29.479 For most of you here, it's great to follow instructions on screen to gauge your code's readability and evaluatability. A score below 20 is ideal.

00:08:40.519 If your code needs to be secure, aim to keep it well below 20. Keeping them small, minimizing branches, and avoiding functions like eval are critical practices.

00:08:46.279 Always invoked: I think the HTML sanitizer in ActionView is a great example.

00:08:51.640 At first, it was something you could call if you wanted, but you could also easily forget.

00:08:58.360 At some point, they integrated it into ActionView, mandating you to call it.

00:09:05.200 I’ve not used Rails lately; I’m one of those weird Ruby people. But this is a C example, and I like having things like this prompted in headers.

00:09:11.720 This encourages the compiler to alert individuals doing foolish things—it's a learning experience.

00:09:19.200 Lastly, tamper-evidence can be tricky to describe.

00:09:24.240 Coal miners used to bring canaries into mines. These would succumb to toxic gas before it harmed the miners, providing an early warning system.

00:09:32.680 In binaries, we do something similar; placing little cookies on the stack that can be devastated if there’s a buffer overrun.

00:09:40.440 This is a simplification and not foolproof, but there's more to learn about ways we protect binaries.

00:09:46.279 I have my checklist, and I want to discuss some controls and assurances regarding those controls and see how we’re doing.

00:10:02.640 We're going to use this checklist throughout the rest of this talk. The use cases I’m discussing represent one example divided into three parts. It doesn’t pertain to any actual system I've built, but I believe they illustrate good security principles.

00:10:20.440 At the base of your system are your operating system controls. No matter how secure your code is, if your operating system isn't configured correctly, you're in trouble.

00:10:40.160 The main security feature of your OS is access control. Security geeks talk about mandatory access controls—they can sound complex, but it's actually straightforward, indicating that something set by the administrator at boot cannot be modified.

00:10:56.720 Mandatory access controls are reliable and don't change, allowing us to ensure that code operates effectively. Thus, using your operating system’s access control mechanisms, preferably in a mandatory fashion, simplifies your system.

00:11:09.000 A use case might be that you have multiple databases, and you want to ensure that users on different networks can only access those databases they are authorized for.

00:11:24.360 You need to be extremely careful about what gets into those databases. Rather than relying on the best practices of our code to prevent SQL injections, we can grant our applications read-only access to these databases.

00:11:40.920 This way, regardless of how poor our network application is, there’s no way it can read from or write to databases it’s not allowed to access. Instead, we implement a little 'glue' router to ensure the right requests go to the right places.

00:11:57.240 This relies on the fact that these databases have read-only permissions, meaning an attacker would need to compromise the entire server to bypass that, thereby giving us reasonable assurance.

00:12:10.080 Evaluatable: the security critical part of this code is just that little router taking write requests and sending them to the database owners. I can keep this code small and evaluatable, potentially using a type-safe language like Rust.

00:12:24.000 Always invoked: every file system call must go through the kernel, assuring it's invoked consistently. I was trying to find an example demonstrating tamper evidence but decided against it to avoid boring you.

00:12:34.640 Some takeaways: use your operating system’s access control mechanisms whenever possible and wrap them into your application, perhaps using Foreign Function Interface (FFI). However, don’t stop there because while implementing these controls during development can be challenging, it is of utmost importance.

00:12:43.360 Doing Day-to-day development with these controls in place can be tedious and even risky, potentially crashing your development environment. Use stubs to sidestep potential complications during development.

00:13:00.800 We reached a point where a third-party was helping us develop our application but didn’t have our Mac infrastructure. Instead, we provided them with this stub they used to code a cool application.

00:13:15.200 When they handed the code back to us, it was relatively easy to integrate it with our application after removing the stub.

00:13:29.440 Remember, implementing mandatory access control only works if the application can't change its own policy. Therefore, be cautious about giving your application system privileges.

00:13:45.200 For example, if a popular library like Stage in Android makes a small mistake, it could have catastrophic consequences if granted system privileges. It's crucial to give such privileges careful thought—making an error means you no longer control your system.

00:14:06.720 One of our objectives is to simplify the creation of test doubles for our file system objects, as we heavily rely on the operating system in security implementations.

00:14:24.320 I have discussed this concept with some people from Test Double, but it still requires further thought and conversation. If you think it’s a bad idea or would like to help, please let me know.

00:14:33.600 Next, moving through the layers of the onion of our use case, I’ll refer to them as our Services Security Framework.

00:14:51.080 If we're breaking our application into various processes, we must integrate them. However, integration points are prime locations for attackers to penetrate your system.

00:15:03.760 Things like interprocess communication or database access can lead to vulnerabilities, including cross-site request forgery (CSRF), internationalization attacks, or SQL injection. It’s often difficult to get clients to understand what can happen without skilled management here.

00:15:19.199 I’m reminded of an insightful moment in Ender's Shadow, where Bean describes that as your attack surface expands, defense becomes untenable. Fortunately, we're not facing a horde of aliens, but the risks are still significant.

00:15:31.920 I don’t have enough confidence, even with our extensive experience, to guarantee our code would be flexible enough to withstand changes over a decade that allow threats to get through.

00:15:51.440 So we follow the principle of separating, isolating, and integrating. Each time a process component is separated based on data, it should utilize a domain-specific language for enforcing security policies.

00:16:05.679 When sending data out, we seek to protect the data and the following process to ensure security.

00:16:20.320 Let’s take an oversimplified example: we want to make sure no semicolons reach storage, as many web attacks rely on them.

00:16:30.480 This isn’t an absolute solution, but it’s a useful policy for many web threats. Please note that the following examples do not consider internationalization.

00:16:45.600 When examining application layer preprocessing, this code appears to be doing some form of escaping that transforms semicolons into alternate characters before storage.

00:17:04.480 It then resolves the escaped character back to the original format upon rendering. While I have trust in this code, it does present some complexity.

00:17:21.199 Imagine applying policies like this to an application with hundreds of such rules; it could get unwieldy.

00:17:31.920 However, the code for the actual storage process is much simpler; it simply looks for semicolons in guidance and only permits data without them.

00:17:43.479 If a semicolon appears in stored data, it indicates either a severe flaw in our application or possible tampering. This example illustrates a form of tamper evidence without high-tech solutions like stack canaries.

00:17:56.320 Ruby is excellent for monkey-patching code into classes, allowing for various hooks to trigger automatically as demonstrated in last talk.

00:18:06.679 The point of this simple check carries significant weight, as the complexity in normalizing data pre-storage allows for single and effective validation.

00:18:17.760 Moving on to more related technologies: if any of you have worked with parsers like Antlr or Treetop, they enable you to customize behaviors in your code for specific parsing tasks.

00:18:35.440 Another fantastic tool is Chek Dosh, a simple bash script that analyzes binaries to provide insights into what sorts of exploit mitigations have been added.

00:18:50.639 We regularly utilize this tool and find various links about security concepts, allowing considerable learning opportunities about binary exploitation by following resources on their site.

00:19:06.560 POC or GTFO is another noteworthy work, often dubbed the 'Why the Lucky Stiff' for security geeks. It's humorously technical, albeit challenging to follow at times.

00:19:15.760 Finally, the Spanner blog discusses web application penetration and remains one of the best sources for this topic.

00:19:26.679 If you've dealt with SELinux or other complex policy frameworks, you'll recognize how powerful and effective they can be. Yet, maintaining the state of such systems can still be challenging.

00:19:40.480 I'm a proponent of simplifying the use of custom-oriented domain-specific languages (DSLs) tailored to the specific issues we face. This is a very Ruby-centric approach.

00:19:55.200 Keep your enforcement checks as simple as possible, as complexity can lead to obscure bugs, such as time-of-check-to-time-of-use issues.

00:20:05.360 These bugs occur when a condition is checked, proceeding to another operation that may inadvertently alter the data during the interval.

00:20:12.919 Complicated conditions can easily lead to these problems; thus, it’s vital to keep checks straightforward to mitigate the risk of these nasty security bugs.

00:20:20.640 I have an example linked here showcasing an incident involving Matt Honan of Wired Magazine, where clever attackers chained minor security oversights into a significant breach.

00:20:35.279 So, next steps. There was a talk Tom Stuart gave in Barcelona in 2014 titled 'Refactoring Ruby with Monads.' I find the concept of monads exciting but don’t necessarily practice it well yet.

00:20:47.560 I strongly believe monads could be used to wrap content we've ingested from trusted sources, ensuring proper validation before storage.

00:21:03.440 Additionally, we’ve considered leveraging immutability for its security properties alongside performance and code quality benefits.

00:21:17.200 There is much we can do to enhance our code’s mechanisms and ensure promised validation.

00:21:28.840 Consequently, we’ve been focusing on improving tools to automate our security rule sets, tackling the occasionally mundane process of manually constructing these checks.

00:21:43.440 Now, back to what affects most of you: writing applications.

00:21:56.400 There are numerous security decisions required in the app layer that can’t be resolved at the service or integration levels.

00:22:09.200 A great case in point is XML—I try to avoid XML when possible, but sometimes it's unavoidable.

00:22:24.240 Building a high-assurance, secure XML processor isn’t just complex; it's highly challenging given the scope of available XML libraries, many of which are sophisticated.

00:22:40.320 Achieving our goals means breaking down the effort into smaller, manageable pieces, then integrating them via well-defined mechanisms that the operating system enforces.

00:22:55.120 A strategy we like to champion is what I define as 'binary diversity'. Utilizing distinct libraries for diverse functionalities complicates an attacker's task.

00:23:10.400 By strategically separating functions and employing varying libraries, we gain a measure of defense—even if it’s just a partial line of protection.

00:23:25.200 As Justin Surl discussed, breaking down functions into smaller components simplifies testing. Validating both simple and intricate mechanisms leads to more robust software.

00:23:43.760 We might have very secure code, but the dangers of vulnerable libraries still lurk. Even reliable libraries like Psych could have obscure security flaws.

00:23:57.440 It's crucial to build fault isolation into your systems. Evaluating where we currently stand highlights challenges we face.

00:24:10.280 We’ve established a solid, non-bypassable pipeline to our storage data, ensuring it's the only path available, equipping it with evaluatable inputs.

00:24:24.159 Our codebase is extensive, presenting somewhat limited scope for evaluation. However, there are ways to ensure your code is reliably invoked.

00:24:38.459 For instance, using Rails, you might employ instrumentation checks that ensure accessibility to your XML, letting those verifications auto-run.

00:24:59.679 The brick wall alerts presented earlier aren't just decoration; they're practical tools like Seccomp, which we frequently utilize.

00:25:14.760 Seccomp acts like a firewall at the OS level: each file read triggers a process that translates requests into opcodes.

00:25:31.919 Many system calls range from incredibly beneficial to those you should never use in a production context—these weaknesses are known to attackers.

00:25:48.120 Utilizing tools like Seccomp secures your application; if there’s a security failure, it won’t compromise the OS entirely.

00:26:02.640 Furthermore, consider using GRsecurity: it’s a controversial patch requiring recompilation of the OS, but it offers significant protections.

00:26:14.840 The Washington Post had an insightful article on November 5th that shared contrasting perspectives on GRsecurity versus Linus's stance.

00:26:30.320 For those interested in the Internet of Things, various tools, including OpenEmbedded, are valuable; however, in my experience, Buildroot shines for creating customized Linux distributions.

00:26:44.640 Ruby is also part of Buildroot's offerings.

00:27:02.000 Looking towards the future, we hope to simplify usage of Seccomp.

00:27:14.160 I intend to create a gem aiding in blocking unnecessary system calls that won’t be needed in a production. You could significantly diminish any application’s attack surface using this gem—although it wouldn’t work on Windows.

00:27:30.919 Next, we emphasize the importance of separating code into distinct processes and ensuring secure isolation as well as integration.

00:27:45.680 Being relentless in testing and designing your code is paramount.

00:27:59.559 I aim to enhance the availability of Seccomp tools for wider community use.

00:28:12.560 Robusta is another cool recent development. It's essentially a container running within the Java Virtual Machine that seals off native extensions if a security compromise occurs.

00:28:27.720 Most Ruby vulnerabilities stem from native extensions that we rely on heavily, so this could be significant for the Ruby community.

00:28:40.320 We’re also learning about MRuby. Unfortunately, a Birds of a Feather session on MRuby overlapped with my presentation, preventing me from attending.

00:28:56.919 MRuby contains robust controls to enhance the security of our binaries, making it incredibly challenging for attackers.

00:29:11.040 Incorporating flags available in GCC and Clang can also strengthen binaries, yielding impressive results.

00:29:26.160 I could share a picture of my cat, but I always find Zach and Cory's briefings entertaining.

00:29:38.240 Now let's briefly touch on security penetration testing. Sometimes I engage in this process, exploring the mystery surrounding penetration testing for those unfamiliar.

00:30:02.919 Recognizing this picture from Lord of the Rings, you'll recall that an outer wall isn't entirely defensive; its purpose is to make attacks more cumbersome.

00:30:14.640 Directing focus onto the outer barriers led to vulnerabilities in Helms Deep, so resources need to be allocated to guard critical areas.

00:30:31.679 When contemplating whether to hire penetration testing services, always provide them with ample information; it allows them to deliver maximum value.

00:30:43.080 Building relationships with your penetration testers can yield invaluable insights. During testing, be transparent and cooperate with them for maximum effectiveness.

00:30:57.200 Don’t merely test from the outside; Ruby enthusiasts know it’s crucial to unit test all classes, no matter how inherently embedded.

00:31:10.640 By allowing testers access from different layers, they can effectively assess your application’s vulnerabilities without compromising the production environment.

00:31:24.200 With that, I appreciate your attendance at my talk. I hope you found it engaging and insightful.

00:31:35.070 I have 10 minutes for questions, so feel free to ask!

00:31:43.080 So the question is: what’s my opinion on getting third-party penetration testers versus just executing automated vulnerability scans? It really depends on your goals.

00:31:57.440 That’s a vague answer, but I believe in balancing between employing automated scans with continuous integration while also engaging human testers.

00:32:13.839 Automated tools are practical, but trained penetration testers can discover vulnerabilities that automated tools might miss.

00:32:31.159 While recognizing the necessity of utilizing libraries, it’s wise to consider that using multiple libraries can widen the attack surface.

00:32:48.639 In my example, though, utilizing REXML for well-formedness allows other libraries to focus on deeper content checks, leading to stronger validation.

00:33:04.960 The practice of using preconditions and postconditions to create a secure architecture can be beneficial. If done right, it can significantly improve security processes.

00:33:17.239 Any other questions? Great! Thank you all again for attending!