00:00:24.130
Hey everyone, my name is Frank Rietta. My background is as a developer, and I have a background in computer science and information security. I'm out of Atlanta, where I work with a company that I started, which specializes in building web applications where security is a priority. I'm here to talk to you about data breaches and how you, as a developer, can help prevent them. History has taught us that when you develop an application and it starts amassing customer data, relying on historically normative means of protecting that information often fails.
00:00:43.600
Consequently, the slides are available on Speaker Deck, and there's a paper that details this topic. If you're interested in a more in-depth version, feel free to check that out. I also have two Blue FIDO Universal two-factor tokens to give away, so be prepared for your questions because that is primarily what we're going to discuss. It could be a question for a friend, something you're dealing with, or something based on this talk.
00:01:05.930
Let me start with a fundamental axiom of security: security is not an on/off switch. You can't just flip on an SSL switch, which would be great because then you could take the data coming from your customers and encrypt it while it's in transit across the network to your services. However, since we can't rely solely on network security, we need to focus on application security. My definition of application security is that it is the area of information security concerned with protecting data and privacy against adversaries who have access to the software system as a whole.
00:01:58.560
The term 'adversaries' is important here because not all adversaries are hackers; they could be federal law enforcement agents or employees who have legitimate access to certain areas but exceed their authorized access. The goal of application security is to make the application itself more resilient against attacks. We're not simply going to hide it behind a firewall or turn on SSL and presume that we have security.
00:02:31.370
So, what is a data breach? To illustrate, consider this stick figure with a floppy disk. An unauthorized person gaining access to sensitive data and having the means to read it constitutes a breach. But there is an important caveat: even if the data isn't accessed, the breach is still defined by the lack of encryption. For example, if you have a laptop with sensitive data locked in your car and it gets stolen, and if that laptop is not encrypted, by law, it represents a data breach because you cannot prove that the person who stole it did not access the data.
00:03:19.230
On the other hand, if the laptop is encrypted, you may argue that there was no breach, as the thieves would have needed the key to access the data. This definition extends beyond physical theft; for example, if someone breaks into your Amazon account and accesses customer data or server instances, you must declare a breach, even if the hacker’s actual activity is not directly accessible. There is simply no proof that they did not access sensitive information.
00:04:11.279
This diagram presents a collection of data breaches over the last few years, where the size of each circle represents the number of records breached. As a developer, it is reasonable to be alarmed by these statistics, but it’s crucial to understand that the fundamental problems are not just problems of convenience. Security is not merely an on/off switch; there are basics we need to address.
00:04:49.110
This chart from the Verizon Data Breach Report outlines web hosting attacks from this year. Of a sample size of 205 enterprise-class systems, over fifty percent of breaches resulted from stolen credentials, particularly from staff members. This highlights the importance of preventing account compromise through strong authentication practices.
00:05:12.200
We must also consider common technical vulnerabilities. For instance, the OWASP Top 10 includes risks such as insecure passwords, lack of patching, and unencrypted backups. Developers should take personal ownership of these issues throughout the development process because weak security, such as unencrypted backups, has led to severe breaches in the past, including the incident involving bit.ly.
00:06:33.570
A notable quote from 2004 by Greg Hoglund and Gary McGraw indicated that most outsourced software is full of backdoors. I prefer to use the term 'vulnerabilities' instead of backdoors, and this aligns with my observations in practice. Security is not traditionally considered a functional requirement, but rather an attribute that can often be postponed. This deferment creates a dangerous situation: customers think developers are addressing security, developers think operations is responsible, and operations might believe someone else is handling it. In the end, no one is taking care of it.
00:07:06.200
As developers, we need to approach development with security in mind. Security should be treated as a fundamental requirement that needs to be addressed from the start. It's important to understand that not all information is equally sensitive. For example, in a governmental context, you hear about top-secret and secret information, while in a business context, we refer to PII (Personally Identifiable Information). However, what's really needed is an effective information classification system to ensure data is appropriately protected.
00:08:01.900
A basic information classification system can categorize data into several tiers, comparing public information with internal data and sensitive information defined by law. For instance, data identified as PII requires significant concern if compromised. Furthermore, there's data that may not be governed by laws but still holds value in affecting a company's reputation and customer trust.
00:08:52.150
Given the need for proper security, one tool developers can utilize is user stories with security constraints. These user stories incorporate security considerations into the development process. For those unfamiliar with user stories, they are descriptive components of functionality that involve conversations clarifying the details and tasks necessary for implementation. For example, when defining user stories, we can include specific security constraints to ensure robust input validation and password policies.
00:09:39.760
By including considerations for what would happen if a password were inadequate or if validation failed, we sharpen our focus on security issues. For instance, if users could create a password shorter than 12 characters, developers are alerted to increase password complexity and implement necessary verification mechanisms. Additionally, when customer service representative features allow staff to log in as customers, it is critical to enforce strict logging and require two-factor authentication.
00:11:02.690
We also need to think critically about private information that customer service representatives should not access. Database rules should restrict access based on necessity, and strong logging must be implemented to monitor staff actions. When responding to subpoenas, it is vital to engage in discussions with system administrators to avoid unnecessary data disclosures.
00:12:16.300
Now let's discuss direct object reference, which is an OWASP Top 10 issue. For instance, if I change the account number in the URL, I might gain unauthorized access to other user data. It’s important to clarify that users (especially non-technical stakeholders) may not consider this possibility, but authenticated users could exploit such vulnerabilities. This emphasizes the necessity of implementing robust security architecture.
00:13:00.540
Furthermore, as a disgruntled employee about to be fired, one might think to delete records or create chaos, impacting data retention and backup strategies. Criminal intent among users introduces significant risks; hence securing profile data and identifying risks while managing user data transparency becomes paramount.
00:14:06.890
Throughout this talk, we've emphasized the importance of structuring user stories to encompass security concerns. This awareness fosters insightful dialogues between business and technical teams about the threats faced by the application. Thus, we cannot simply adopt security practices as an afterthought; robust countermeasures must be integrated into the fabric of our application's development process.
00:14:56.020
Finally, it's vital for developers to familiarize themselves with the OWASP Top 10 vulnerabilities because these categories represent common risks across all web applications. The solutions are not unique to any framework like Rails or Sinatra; instead, they are universal practices aimed at enhancing security across the board. Enabling secure headers, forcing SSL, and employing automated tools such as Brakeman or Bundler Audit to detect vulnerabilities are vital steps we can take towards securing our applications.
00:15:37.670
Additional measures include utilizing encryption standards and practicing solid encryption measures for sensitive data. Such practices should not be mere suggestions but should be enforced as critical standards, particularly when working with historical data within legacy applications. We need to wrap up by reiterating that data breaches are a significant concern that won't disappear on their own. Your system is under constant threat, and you're the last line of defense.
00:17:17.930
Application security means preventing abuse by adversaries who may have access to your system. Poor security assumptions can lead to severe consequences. Implement an information classification system, treat security as a paramount requirement, and leverage user stories to mitigate vulnerabilities. Additionally, strong encryption and practical countermeasures are essential; two-factor authentication, in particular, must become the standard rather than the exception.
00:18:40.320
Ultimately, security requires a defense-in-depth strategy employing multiple concurrent controls to protect sensitive data and user information. Security is not merely about technical measures; it involves a cultural commitment to prioritize security at every level of the organization. As such, we must work proactively to ensure the integrity and security of our applications.
