Application Security

Summarized using AI

No Such Thing as a Secure Application

Lyle Mullican • May 24, 2019 • Minneapolis, MN

In the presentation "No Such Thing as a Secure Application" delivered at RailsConf 2019, Lyle Mullican explores the nuanced concept of application security, emphasizing that true security is not a checkbox but a risk management process. He outlines the importance of defining what security means in the context of software development and advocates for a proactive approach in integrating security into the development lifecycle.

Key Points Discussed:

  • Security vs. Functionality: While developers are adept at defining functional requirements for software, there is a notable lack of tools for expressing security needs. This oversight leads to vague assumptions about security in applications.

  • Understanding Security: Mullican points out that security is fundamentally about managing risk, involving specific controls tailored to mitigate identified threats. Instead of asking if an application is secure, we should inquire about the ways in which it is secure or insecure.

  • Defining Threats: Establishing a threat model is crucial. This involves identifying potential threats, assessing their likelihood and impact, and prioritizing them based on risk.

  • Testing Security Controls: Effective security requires rigorous testing of the implemented controls through various methods, including:

    • Explicit Tests: Tests that validate if security measures behave as intended.
    • Static Analysis: Tools like Brakeman that assess code structure for vulnerabilities while not executing the code.
    • Dynamic Analysis: Running the application and testing its response to various inputs which can uncover hidden issues.
    • Manual Testing: Engaging experienced testers to identify vulnerabilities that automated tools may miss.
  • Resilience and Incident Response: Security incidents are inevitable, so rapid detection and a clear incident response strategy can mitigate damage. Mullican describes easy-to-implement strategies to improve response, such as trap routes that alert developers of probing attempts.

  • Cultural Aspects of Security: It is essential to foster a security culture within organizations by encouraging documentation and structured security discussions. This helps shift conversations from blaming individuals for security failures to improving overall systems and processes.

  • Useful Tools and Resources: The presenter recommends several tools and resources for securing Rails applications, including Breakman, Bundler Audit, and OWASP guidelines.

In conclusion, Mullican emphasizes that while no application can be completely secure, developers must adopt a robust approach to security that includes consistent testing, risk management, and open dialogues about security practices in the context of business needs and technological challenges.

No Such Thing as a Secure Application
Lyle Mullican • May 24, 2019 • Minneapolis, MN

RailsConf 2019 - No Such Thing as a Secure Application by Lyle Mullican

_______________________________________________________________________________________________

Cloud 66 - Pain Free Rails Deployments
Cloud 66 for Rails acts like your in-house DevOps team to build, deploy and maintain your Rails applications on any cloud or server.

Get $100 Cloud 66 Free Credits with the code: RailsConf-19
($100 Cloud 66 Free Credits, for the new user only, valid till 31st December 2019)

Link to the website: https://cloud66.com/rails?utm_source=-&utm_medium=-&utm_campaign=RailsConf19
Link to sign up: https://app.cloud66.com/users/sign_in?utm_source=-&utm_medium=-&utm_campaign=RailsConf19
_______________________________________________________________________________________________

A developer's primary responsibility is to ship working code, and by the way, it's also expected to be secure code. The definition of "working" may be quite clear, but the definition of "secure" is often surprisingly hard to pin down. This session will explore a few ways to help you define what application security means in your own context, how to build security testing and resilience into your development processes, and how to have more productive conversations about security topics with product and business owners.

RailsConf 2019

00:00:20.869 Good morning, everyone! Probably a few more people will straggle in here, but I'll go ahead and introduce myself.
00:00:27.360 My name is Lyle Mullican, and I'm a consultant based in the mountains of Asheville, North Carolina.
00:00:32.730 I've been using Rails for a long time, since version 1, and a lot of my work is in the healthcare sector, where we take security very seriously.
00:00:39.660 So we're going to talk a little bit about application security this morning. It's been my observation over the course of my career that development teams have a lot of tools for specifying the features we expect our software to have.
00:00:53.100 We have user stories, wireframes, and mock-ups, but we don't have nearly as many tools for expressing the security characteristics that we expect our software to exhibit. There are companies with those tools that do a great job of this and have a very strong security culture. If you work for one of those companies, that's great, but for many developers, especially in smaller teams and startups trying to get off the ground, we are often very focused on making the software work.
00:01:11.369 We aim to make it do what it's supposed to do, and we have well-defined expectations for user-facing behavior, alongside a vague expectation that along the way, it's going to be written in a secure manner—without a clear definition of what that actually means.
00:01:36.149 Occasionally, you might end up having conversations like this, particularly after there's been a well-publicized security incident in the news. A boss or possibly a client product owner might ask questions about the security posture of an application, asking something like, 'Is this application secure?' Or if they're slightly more sophisticated, they might ask, 'How secure is the application?'
00:01:54.929 There's an assumption built into this kind of questioning that security is something we can actually achieve; that it's either a box we can check, or perhaps a spectrum with insecure on one end and secure on the other, where we know we're somewhere in between, trying to move closer to the secure end of the spectrum.
00:02:27.299 However, if you stop and think about the security features that we actually build and the kinds of security controls we try to implement, you quickly realize that this isn't how security works at all. So what are we talking about when we use the word 'security,' particularly in the context of software? We are really discussing risk and how we manage it.
00:02:58.530 The controls that we put in place are designed to limit the risks our software faces. Security becomes a kind of verbal shorthand for saying we believe we’ve accurately assessed the risks that our software faces, and that we’ve applied technical controls to bring those risks to an acceptable level for our business.
00:03:37.150 That phrase 'acceptable level' is crucial, and we will come back to that later. Any security control typically addresses a specific scenario, often at a single point in time.
00:03:57.099 People often use metaphors with security; for instance, consider living in a castle with towers and big stone walls. You might ask yourself if you are secure.
00:04:08.620 Well, it all depends on your threat. If your threat is a medieval land-based army, you're reasonably secure against it. However, if your threat is a modern army with modern technology, you're probably not secure at all.
00:04:19.690 A more technical example could be HTTPS; it has the 'S' right there in the acronym, standing for secure. To the general public, when they access a website and see that 'S' in the URL bar along with a little padlock, it signals a secure website.
00:04:37.240 As technologists, we know that it’s not the website that is secure. HTTPS tells us nothing about what the website is doing with our information. It's the connection to the site that's secure, and even then, it only secures against very specific scenarios that HTTP was designed to address.
00:04:56.040 Thus, any definition of security can only be based on a clear definition of a threat. Instead of asking whether something is secure, we should be asking: in what ways is it secure or not secure? I’d like to break that down into a few basic questions.
00:05:14.340 These are questions we should ask ourselves routinely as we build software. We can ask them at different levels and contexts, such as at the level of code when we introduce a new method or when we change the behavior of a method, or we could ask them about the system as a whole—our software application in general.
00:05:43.320 The first question, and really the first two that go together, is what we call a threat model. This includes defining what we're worried about: what could go wrong in a security-relevant way? What could cause harm to the software, to the business, to its users, and how likely are those issues to actually occur? Once we understand that, we can ask ourselves what actions we could take to mitigate those threats.
00:06:10.020 We recognize that we will always need to make trade-offs. Often, the hardest question for developers is not what the threats are but how we prioritize them. We need to determine what deserves the most attention and what the acceptable level of risk is for a business.
00:06:40.860 The most secure design we can develop may ultimately be impractical. For instance, if I’m deeply concerned about SQL injection—and I am—I could design a system where my application isn’t allowed to communicate with my database at all. I could make the application output questions on paper that a DBA interprets and manually executes on an air-gapped machine.
00:07:02.520 While this provides robust protection against SQL injection, it’s entirely impractical. Hence, we have to recognize we will land somewhere between that impractical design and a database that is publicly accessible on the Internet.
00:07:31.380 There are trade-offs we need to make regarding the security features we implement. So, how do I determine which ones are really necessary and which need immediate attention? I'll discuss one way to think about this; it’s certainly not the only way, as there are numerous approaches to developing a threat model.
00:08:06.170 When we talk about prioritization, we should consider this as a conversation. You can use a whiteboard with your team and start addressing these issues along two axes: one axis should measure the likelihood of a threat occurring, while the other axis should measure the potential damage if it occurs.
00:08:41.700 This approach is quite subjective, allowing us to establish starting points. While we can't quantify the statistically probability of a specific attack occurring, we can compare scenarios based on our insights from industry trends, our application logs, or the nature of our business.
00:09:11.970 The idea is to establish priorities by identifying which threats are worth our attention. Some threats are common due to their ease of automation, while other threats may be less likely because they rely on targeting.
00:09:37.860 However, unlikely scenarios can still pose significant risks, and recognizing this allows us to prioritize effectively. By comparing threats this way, we can focus on those that are both likely to occur and likely to cause meaningful harm, ensuring they receive our primary attention.
00:10:13.529 This prioritization should also be revisited continually, as no threat model is ever complete. Much like when we iterate on our product prototypes, we should iterate on our security threat assessments as well.
00:10:32.519 Once we have a model documented, we can begin to ask further questions: What do we do about these threats? What controls do we already have in place? Where are our gaps? How can we prioritize efforts to close those gaps?
00:10:48.779 The good news is that designing security controls is typically straightforward because many other organizations face the same problems I do. Experts have already thought of effective solutions to address common vulnerabilities.
00:11:20.579 For example, we know how to prevent SQL injection and cross-site request forgery, but the real challenge lies in implementation. One key question is how to assess whether our existing security controls are effective.
00:11:49.630 The answer lies in the same way we determine if our software behaves as intended: we need to test it. My own journey as a developer saw me gradually adopting test-driven development principles and embracing automated testing.
00:12:09.730 Before transitioning to Rails, I primarily worked with PHP and found myself entering code in a text editor, opening my web browser, and hitting refresh to see if my changes worked. Eventually, I realized that method doesn't scale, and I recognized the undeniable power of automated testing.
00:12:43.290 Once I began to write effective tests, I discovered that learning to test compelled me to write better code. It made me think more critically about the code I was producing, and I believe that security testing will have the same impact.
00:13:10.730 When considering how we’ll test the security controls we implement, we typically design better security controls. Therefore, security testing should be a significant part of your testing suite, integrated into your CI pipeline.
00:13:38.290 If you're not testing your security controls, someone else probably is, and you definitely don’t want to leave security testing to chance. There are several types of security tests we can utilize, and I’ll highlight a few categories to approach security testing.
00:14:12.050 The first type of security testing involves explicit tests for controls built into our applications. This resembles testing any other application's behavior. For example, in Cucumber, we might validate access control to ensure that a user can only view their own orders.
00:14:37.320 In the test, not only do I confirm that access is denied when attempting to access someone else's data, I also assess what the response is when I try.
00:14:58.100 These explicit tests cover exactly what I instruct them to since they will alert me if any security controls fail to operate as designed. However, they won’t catch vulnerabilities that I'm not already considering, which is where other testing types come into play.
00:15:19.740 The next category is static analysis testing, achieved using various tools. For instance, I'm sharing output from a tool called Brakeman, which many of you may already be using. It identifies potential SQL injection vulnerabilities by analyzing whether user-controlled input is passed into ActiveRecord class methods without sanitization.
00:15:45.690 Static analysis excels at tracking input handling across multiple levels of indirection, something that’s difficult for humans to do. These tools don’t execute application code; they analyze its structure.
00:16:09.970 However, false positives can occur during this analysis, which can be frustrating for developers. I personally view a false positive from Brakeman as a code smell, suggesting I've made my code too complex for Brakeman to interpret.
00:16:31.320 Another vital aspect of static analysis is auditing dependencies. Most applications utilize not only their code but also external gems and other dependencies with potential vulnerabilities.
00:16:56.370 As part of a comprehensive automated security testing strategy, auditing the state of gems is essential. One tool I use for this purpose is Bundler Audit. It accesses an open-source Ruby advisory database, checking for missing patches or version upgrades in my Gemfile.
00:17:23.170 The next category of security testing is dynamic analysis. Unlike static analysis tools, which don’t execute code and only evaluate its structure, dynamic analysis tools run code without understanding its internals, analyzing the outputs instead.
00:17:51.790 In the business world, dynamic analysis might be regarded as traditional security testing. It generates unexpected inputs to see how the application reacts, which is useful for identifying potential string handling issues, even if they don't represent specific security vulnerabilities.
00:18:20.410 It’s wise to grant these tools access to an authenticated user account, as applications may have stringent security protocols for public access, yet trust levels can be improperly assigned once a user logs in.
00:18:47.710 Allowing a dynamic analysis tool to probe an application can yield significant insights. Furthermore, this approach can effectively exercise the entire application stack by running requests through the server and all relevant gems.
00:19:15.480 The fourth category is manual testing, which can be costly in terms of time, money, and expertise. However, human testers can do things that automated tools can’t.
00:19:43.690 A skilled tester can gain insights into an application's behavior, drawing on their development experience to make educated guesses. They may start with automated tools to identify potential vulnerabilities and then proceed with manual probing.
00:20:05.070 Manual testing is particularly critical if you're dealing with sensitive data. Organizations can deploy dedicated teams, implement bug bounty programs, or hire consultants for penetration testing.
00:20:27.900 Conducting manual security testing offers invaluable insights that automated tools may miss, especially in context of sensitive data.
00:20:47.670 The concept of defense-in-depth frequently arises in security discussions and applies to testing strategies. None of these methods are mutually exclusive, and it’s advisable to combine them for maximum security.
00:21:23.540 The idea of defense-in-depth refers to layering security controls, providing multiple opportunities to prevent failure. For instance, imagine a web application firewall monitoring traffic for malicious patterns—a strong layer of defense. However, should that layer fail, we still ensure our application sanitizes input effectively.
00:22:05.320 If an SQL injection vulnerability exists within the app, it is crucial to enable least privilege access levels to the database user. Therefore, even in the event of a successful injection, it’s limited in capability.
00:22:43.110 Defense-in-depth strategies should be applied to testing, as none of the aforementioned approaches are flawless. By layering them, we enhance our confidence in identifying as many vulnerabilities as possible.
00:23:00.760 Now I want to discuss what happens when an attack is in progress, particularly when applications potentially have unresolved issues. Incident response is a vast topic, but one key aspect involves recognizing that exploits take time.
00:23:33.940 It takes time for an attacker, whether they’re using an automated script or manual probing, to discover vulnerabilities and find successful exploit methods. Most security discussions focus on prevention strategies to lock down applications and secure them from malicious activities.
00:24:10.060 This includes the critical need to detect attacks timely. If we have existing vulnerabilities, early detection and swift action are essential. There are simple, effective methods to strengthen our incident response, even in smaller applications.
00:24:51.260 For example, implementing a non-existent route with a simple yet predictable path can reveal unsuccessful probing attempts. If a user attempts to access it, they receive a 404 error—and spying on this pattern helps us identify areas of concern.
00:25:27.150 I proposed connecting it to a controller I’ve dubbed 'Tripwire.' If an authenticated user triggers this route, I can send notifications to my team, alerting us that potentially malicious activity is occurring.
00:26:05.620 Another common probing tactic is to ascertain the technology stack. For instance, suppose a user probes a WordPress path. If this occurs, we can respond by blocking that IP address altogether.
00:26:42.780 IP blocking like this is highly effective, albeit not necessarily the most efficient method of managing IPs through application code. However, in smaller applications, these measures can yield significant benefits.
00:27:11.640 For efficiently managing and responding to these instances, store those flagged IPs in cache with a time limit to deny access without inundating your resources.
00:27:45.070 For any incident response plan, the crucial thing to remember is to limit the number of decisions made under pressure. Questions such as how to block an attacker should be pre-established before an incident arises.
00:28:18.230 While you may not encounter the exact situation you’ve anticipated, planning equips you with tools to adapt to unforeseen events in the real world. In speaking about preparedness, I want to emphasize that risks cannot be fully controlled.
00:29:06.040 There will always exist a certain level of risk when using software connected to the Internet. While it's important to engage in preventative measures, dealing with incidents effectively is equally crucial.
00:29:43.480 Resilience is a concept we can apply at multiple levels: to software, to individuals, and to organizations. We must ask ourselves how our software is designed to handle failures. In security terms, this may include how we store data, segregate networks, and layer controls.
00:30:12.790 On the human side, resilience refers to our responses when code fails. When we discover vulnerabilities in others' code, how do we process that? Do we play the blame game or do we strive to learn and prevent recurrence?
00:30:55.430 Impostor syndrome is widely discussed in the community; many developers fear that others possess more knowledge, leading to apprehension about being 'found out.' In security-related contexts, this fear may intensify, as security failures tend to attract moral judgments that other bugs do not.
00:31:33.580 We must remember that security is inherently challenging, primarily because defenders must be correct at all times while attackers only need to succeed once. During security discussions, we must consciously avoid framing our language in ways that imply systems can be flawless.
00:32:05.530 Understanding that there is no such thing as a secure application is essential. However, we must also engage in security discussions with those who may harbor naive views of how security functions in business.
00:32:51.920 The tools we’ve discussed can assist in reframing conversations. When someone suggests it should all be foolproof or that certain security measures should have been well known, we can reference documented approaches that involve both technical and non-technical stakeholders.
00:33:14.290 Documentation aids conversations about security expectations, and having security testing integrated into automated testing provides transparency. Planning and discussions about how to respond to trustworthy events can cultivate a culture of security.
00:33:28.640 With structure established, security conversations shift from blaming individuals to analyzing how to improve processes. Reflecting on our approaches leads to understanding whether our threat models and tests could be more robust.
00:33:38.189 I encourage you to explore the tools I’ve mentioned, including Brakeman, Bundler Audit, and Raccattak, which can help enhance your security strategy.
00:33:44.149 Additionally, there are helpful resources like the Rails security guide from the Rails documentation, the OWASP guide for secure coding practices, and the annual OWASP Top Ten list detailing recurring security issues.
00:35:07.020 The U.S. Computer Emergency Response Team (CERT) tracks vulnerabilities and publishes relevant feeds. These resources can enhance your understanding of security within the industry.
00:35:27.570 Thank you very much! Feel free to find me at the conference if you have any questions or want to discuss security further.
Explore all talks recorded at RailsConf 2019
+102