The most vulnerable part of most organization’s network infrastructure is their browser. This is because it is a gateway to major attacks, primarily through malicious websites. This is also true for a government organization such as NASA.
Network Security and Endpoint Security generally both depend heavily on the concept of Assurance. Assurance means enacting the proper Policies, Permissions, and Protections to make browsing safe. In order to gain this assurance and enact effective policies, organizations should have insight into the inner workings of browsers and how they handle code running inside of their application walls.
Browser security at NASA is extremely important, but at the same time extremely hard to get right. As an organization, there is a need to be smart about developing Assurance for users by creating Policies and provisioning Privileges that Protect everyone while preserving performance.
In this article, I’ll be showing you a technical breakdown of how to develop a browser that uses Artificial Intelligence to create dynamic use policies based on real-time threat intelligence. As a user, this dynamic policy creation, provisioning, and enforcement should be seamless.
The browser is code-named Jemison. One of its major benefits is to offer fewer roadblocks in the form of analog permission requests, fewer restrictions on the range of sites you can visit, and overall less worry about visiting suspicious websites. Let’s ride.
What Is The Objective Of The Security Plan
The basic objective of this security plan is to create real-time rules for browser behavior that apply to a wide range of activities. These rules are remotely enforceable and utilize machine learning to make real-time decisions about security. To fully explain the security plan, I’ll:
- Describe the type of threats we need to secure against
- Investigate how the Chrome Browser works and provide an introduction to the Chromium Open Source Project
- Outline how we can make a new, safer browser upgrading the Chromium Process Manager
- Propose ways we can measure success and implement effective threat modeling
This article will primarily focus on the types of threats we need to protect against and how we can engineer a solution. It will not address legal or budget concerns.
What Is The Scope Of The Security Plan
This security plan will primarily focus on the types of threats we need to protect against and how we can engineer a solution. It will not address legal or budget concerns.
More so, it will have a sharp focus on Chrome and the way it handles browser activity and security. Chrome, one of the most popular browsers, is based on an Open Source Project, Chromium. While the Chrome source code is not open, the code that is used to build it is. This section provides the scope for our security development roadmap.
The scope of the security plan is fundamentally classified under the general target, general audience, and affected systems:
#1. General Target
A browser is an application launchpad, an application container, and the door to data storage. Desktops, laptops, phones, tablets, and even some TVs have browsers. This security plan and the development efforts will include all devices that contain a Browser, or the capabilities to have a browser.
#2. General Audience
Users operate browsers, and their actions in the browser may cause the organization to be vulnerable to attacks. We need a way to allow most actions but limit the scope of these actions, so mistakes don’t lead breaches. Therefore our security plan will focus on creating smart, dynamic policies around user behavior in the browser, policies that protect users and do not impede their work.
#3. Affected Systems
Browser Navigation Rules or decisions about websites users can visit are usually handled by endpoint protection. The components involved in aligning the endpoint security management systems include an operating system, an updated antivirus software, and a Virtual Private Network (VPN) client.
However, there are many instances when the user intentionally or unintentionally turns VPN and antivirus OFF, breaking most traditional endpoint detection. The solutions discussed here will seek to protect the user, even if these two layers of protection are gone.
Who Are The Development Stakeholders?
To make this project a reality, there are three tiers of developers, which can be categorized as follows:
- Product Managers from Security Operations will be responsible for creating the product requirements.
- System Engineering will be responsible for the technical requirement and the developing solution.
- Quality Assurance will be responsible for developing acceptance criteria and performing UAT.
Technical Description For Building A Secure Browser
Chromium development starts with understanding the Chromium codebase. First of all, Chromium is not the Chrome Browser itself. The Chromium Open Source Project, much like the Mozilla Project, is supported by the community. Also, Chromium’s multi-process architecture is a radical departure from other web browsers.
This multi-process architecture makes each tab its own process managed by the Chromium Central Process Manager. Our approach is to leverage this architecture to create dynamic policy enforcement while preserving the user experience and performance. We’ll discuss the fundamental parameters and salient subjects of the development:
#1. Chromium Central Process Manager
Separate processes for each tab helps achieve a number of amazing innovations. First, the code running in that tab’s process also has its own thread and its own memory block. Here is an overview of the sandboxing architecture:
“Given the renderer is running in a separate process, we have the opportunity to restrict its access to system resources via sandboxing. For example, we can ensure that the renderer’s only access to the network is via its parent browser process. Likewise, we can restrict its access to the filesystem using the host operating system’s built-in permissions.
In addition to restricting the renderer’s access to the filesystem and network, we can also place limitations on its access to the user’s display and related objects. We run each render process on a separate Windows “Desktop” which is not visible to the user. This prevents a compromised renderer from opening new windows or capturing keystrokes.”
Chromium’s architecture mimics the type of isolation that processes are given when running in a modern Operating System. This type of architecture is ideal for creating and enforcing custom security policies.
If we can actively control the policies used to make decisions in the browsers and dynamically grant permissions to processes running inside tabs, we can do a better job at protecting the users from harming themselves or the organization without impeding access to legitimate sites or slowing down performance.
Google built Chromium with security in mind. However, its policy management features are a little outdated, slow, and relatively weak. Google pointed out this weakness in an online comic they used to announce the Chromium project in 2008. The security API is public, however, and they did this with the idea that the community would improve on the design.
#2. Active Police Agent AI Agent
Our idea is to create an Active Policy Agent AI Agent in the Broker module, one ideally updated by private blockchain like the one in BETA at Oasis Labs. The policies in the browser could be updated from a reliable source in real-time while the AI module makes decisions about safety based on derived variants of the threats before they are found by threat researchers.
The Active Policy AI Agent operates under the basic principles of Threat Hunting. It is updated by a trusted source using Private BlockChain Smart Contracts, and it relays Threat Intelligence using BlockChain back to the security team for analysis, alerts, and actions. When I described some new ideas of this system to a classmate, their initial response was:
With the Active Policy AI Agent and a system that relays the behavior of users back to the Security Team, there would be no need for “pitchforks and torches.” Making decisions about a particular Chinese website, or a certain version of the Flash Player based on real-time threat intelligence and the actual processes running in the tabbed sandbox of a user’s browser eliminates the need for most analog “permission granting.”
Using Oasis Labs Testnet and a fork of the Chromium Project, I’ve started the development of an Active Policy Agent AI.
#3. Passwords
The Active Policy AI Agent doesn’t just need to scan for malicious code or suspicious websites; it can be configured to ensure that passwords are strong and memorable. The best passwords are long, include several different types of characters and most importantly, can be remembered. Forcing users to pick long passwords that they can’t remember leads to a much worse CyberSecurity no-no, saving them in a file called “passwords.” Quoting myself:
“We all remember lyrics from songs, or lines from movies, or famous quotes. If we intersperse these with numbers and special characters, we can make a pretty strong password. For instance, many people know this quote: “Hello, my name is Inigo Montoya. You killed my father, prepare to die.” What if we converted that to HmniIMykmfPTD747#! … Here I just used the first letter of each word in the phrase and capitalized the Hello, Inigo Montoya and Prepare To Die, then added 747, hash, bang.”
The Active Policy AI Agent will sense when the user is picking or using a password and can provide prompts that help the user create a strong password using the method above, almost like an Alexa service.
Policy Agent: “Looks like you are choosing a password, would you like some help?”
User: Sure.
Policy Agent: “Great, think of a line from your favorite movie or song. Don’t write it down, just think of it. Choose something you know like the back of your hand”
User: Ok, got it.
Policy Agent: “Ok, now use the first letter of each word in that phrase to create your password, capitalizing words like names or key points … then add a small number and a special character that you can remember. For example: ‘Show me the Money!’ -Jerry Maguire … would be ‘SmtM!JM747#!’”
How To Troubleshoot The System
Troubleshooting in this security plan means uncovering threats before they happen and avoiding false positives. Nobody wants to use a Browser that is constantly impeding their browsing experience, and yet the security team wants to stay two steps ahead of attackers.
By adopting the Threat Hunt Model, we can analyze browser activity and use the findings to enforce policies for users across the organization. However, threat hunting is not enough. To be successful, we need to create standards around communication and make the threat hunt model a mindset.
The traditional definition of Threat Hunting is “the process of proactively and iteratively searching through networks to detect and isolate advanced threats that evade existing security solutions.” The problem in most modern security plans is that the threat hunters, system engineers, and help desk agents don’t communicate.
If we imagine each of these positions as a part of the human body, white blood cells, red blood cells, and the sensory system respectively, we can imagine how the lack of communication can lead to massive dysfunction.
By integrating AI into the browser as a policy agent, we are effectively making the browser a threat hunt agent, which is powerful. However, if we fail to communicate across teams, we will still fail to take action when it is most needed.
Developing the capacity to troubleshoot the system and its effectiveness involves a radical paradigm shift. If all of the people described above take on the mentality of a threat hunter, the level of organizational vigilance is raised exponentially.
There is broad agreement in the Threat Hunting community that effective classification leads to better data analysis. As a former Pandora engineer, I agree. Proper classification makes predictive systems exponentially stronger, much like a twined rope.
Procedures And Policies To Implement Threat Hunting Troubleshooting
Here are some concrete actions, policies, and procedures we can take to improve troubleshooting in the threat hunt paradigm:
#1. Help Desk Ticket Cross Analysis
This will help us understand a user’s request in context. A simple request for privileges, or access to a site can be harmless when evaluated in isolation. Help Desk Agents should have access to the real-time analysis captured by the Active Policy Agent AI and use this data to make better decisions about access and permissions.
#2. Threat Modeling
This is a well-known practice, but the results of this research are not always distilled down to policies that can be consumed by machine learning engines. As a part of increasing the effectiveness of the Active Policy Agent AI, the security team will work hand in hand with Data Science to train new models as they surface in the threat landscape.
#3. Regular Joint Cyber Security Debriefing
There should be regular joint cybersecurity briefing with representatives from SecOps, Engineering, Human Resources. And each Business Unit (Research, Finance, Operations, etc.) should be held on a bi-weekly basis. The purpose of the meeting should be to share information about threats and help reinforce CyberSecurity principles.
#4. Feedback Mechanisms
The feedback mechanisms in the browser should be at the ready and easy to use. When users have problems with the browser, they should be able to quickly report issues. This will also include crash reporting. The best feedback mechanism only requires a few clicks, captures the user sentiment and relays a snapshot of the browser’s log back to the Engineering Team.
My Recommended SecOps Vendor
ExtraHop is one of my favorite SecOps Vendors. It has an amazing dashboard that allows SecOp Engineers to see threat intelligence from several different perspectives with a few clicks. As a NASA employee, I was able to demo the software and see the way their dashboard helps organize the flood of information coming from the myriad of devices on the network.
It’s no wonder SecOps Engineers are overwhelmed. Without the proper tools, it is literally impossible to make sense of the activity happening within an organization’s network.
“The core of ExtraHop technology is a passive network appliance that uses a network tap or port mirroring to receive network traffic, and then performs real-time full-stream reassembly to extract application-level protocol metrics and other custom-specified information contained in the transaction payload.
A subset of these metrics is sent to the cloud where they are used as machine learning features to detect anomalous behavior that could indicate a data breach, for example.”
Almost like the Alexa device sitting in our kitchen, ExtraHop is always listening, trying to understand if what it hears is normal or anomalous. This type of constant listening is pretty useless without tools that will make sense of the data.
Threat Modeling and Classification is an important part of the ExtraHop value proposition, but it may be hard to believe. However, knowing that threats are never one dimensional helps software like ExtraHop detect threads of activity that may represent malicious behavior.
In the case of the breach at the DNC, there were several clues discovered in hindsight that would have tripped alarms: logins from strange locations within impossible timeframes, the elevation of user privileges followed by large movements of data. Yes, malware unlocked the door but breaking the lock alone was not the point of the breach. Network analysis, like the type offered by ExtraHop, could have stopped the hackers from getting the goods.
The screen above shows a visual network mapping of an event and how it has propagated through a network.
This screen shows aggregated data analysis that classified a chain of events as an attack.
Why Do You Need A Secure Browser In Your Organization?
Web Browsers are a popular surface for attacks because they may provide an open door to the World Wide Web. Most can execute code in a powerful Virtual Machine, and yet their regular use tends to lull users into a relaxed state, one in which they lower their guard.
Even the most vigilant user can miss most of the I/O happening in the browser’s ecosystem, i.e. cookies, cache, files sitting in the downloads folder, and more. Most of the software that protects endpoints does so by trying to intercept URLs but cannot protect against code that executes in a browser session once the user is already on a site.
Safe Browsing means more than just avoiding malicious websites. Threat actors can attack the browser from many different vectors. Security in the browser involves thinking about all the areas where user data is held and how this data is managed.
It involves understanding how scripts run while visiting a site, and understanding how a site verifies its authenticity. It further involves managing the user’s ability to install plugins to the browser or use the browser to run outside applications.
The Diamond Intrusion Model describes how to understand threats beyond two-dimensional ideas that only look at an intruder and a victim. Instead, the author challenges us to understand the entire kill chain and how threats develop.
“In its simplest form (Figure 1), the model describes that an adversary deploys a capability over some infrastructure against a victim. These activities are called events and are atomic features. Analysts or machines populate the model’s vertices as events are discovered and detected.
The vertices are linked with edges highlighting the natural relationship between the features. By pivoting across edges and within vertices, analysts expose more information about adversary operations and discover new capabilities, infrastructure, and victims.”
If we accept the assertions of the Diamond Model, it is easy to understand why traditional methods of browser security are inadequate. Adversaries are not the malware we find in our networks or the vulnerabilities we uncover in software.
Adversaries are people who develop capabilities. Whether these capabilities include exploitation of a software flaw is not of a major consequence. Sometimes exploiting software is not necessary as the user can be seduced into using the software in the wrong ways. Quoting the Diamond Model again:
“…an adversary does not operate in a single event against a victim, but rather in a chain of causal events within a set of ordered phases in which, generally, each phase must be executed successfully to achieve their intent.”
Overcoming traditional antivirus or finding a hole in the firewall is akin to jumping a fence and finding an unlocked window. The breach event is not the objective, and it was not achieved without understanding the environment.
By delivering and positioning AI at the frontline, inside the browser, we effectively empower the “unlocked window” to lock itself because it recognizes that the family is asleep every evening by 10 pm. Also, the smartphones of the owners that are usually always in their pockets are on their chargers (not outside of the house), and nobody has ever approached the window from the outside at 2 am in the history of recorded events.
This smart decision making pushed to the edges of the network represents the future of security not just for Browsers but for IoT devices as well. Pushing this smart decision making into the engine that runs the browser is a good first step.
Conclusion
A secure browser is totally achievable using Chromium open source development. But it doesn’t stop at developing a security plan. The users must also adhere to the security policies set in the organizations to ensure that they don’t give room for malicious attacks of any sort.
