The 2016 Secure Iowa Conference was held in Ankeny, IA on October 4th, 2016. Dwolla was honored to be requested to speak at the conference as organized by the ISSA Des Moines Chapter. The following blog post comes from Dwolla Director of Information Security, Ben Schmitt, and it provides a summary of his presentation, “Using Math to Move Beyond Rules and Signatures”.
After being requested to speak at the Secure Iowa Conference, I reflected on recent challenges, technology developments and the difficult task we have when defending our organizations. I considered a few topics—a technical talk purely about a tool or technique would be nice but it wouldn’t be strategic. On the other hand, a thought leadership talk would be a great way to demonstrate strategy, but it may not provide the technical content the attendees expect. My goal was to “kick a field goal” and support a strategy/vision with techniques to appeal to a wider audience.
The thesis of the presentation was, “Using Math to Move Beyond Rules and Signatures” and the main message was that adversaries can and do buy the same technology as the rest of us. Further, we can’t rely on stock rulesets and signatures—these alone are just a foundation for defense, not a holistic strategy.
There is another commonality between these foundational elements of InfoSec: anyone, including our adversaries, can buy them. We’d be foolish to think adversaries don’t have racks of the same security gear and software we use to polish their exploits. For example, VirusTotal is a wonderful resource which combines the intelligence of more than 50 AV products via an API. An adversary can make this API call part of their integration tests with full automation.
We need to move beyond guidelines and begin using math as an advantage against our adversaries. This notion can be expressed in an adversary-based function, which is visually demonstrated below:
Our adversaries will surely discover our thresholds, rate limits, timing differences, possible side channels, vendor weaknesses, security parameters, technology stack and even the habits of our organizations. Adversaries will profile our social media presence, probe our attack surfaces, masquerade as paying customers and use Open Source Intelligence (OSINT) to learn whatever they can. However, there isn’t a rule in a stock Intrusion Detection System (IDS) which alerts when a sysadmin “shares” their credentials.
We can use math as an advantage when dealing with our adversaries:
- Adversaries likely can’t break the cryptography supporting your Yubikey or MITM a push notification.
- Adversaries probably don’t collect all of your logs, correlate and examine behavior using statistics.
- Adversaries may not anticipate well-placed and high-value honeypots/tokens.
Let’s bring Moneyball to InfoSec: let’s apply the principles of math to help us succeed in our mission. For those familiar with the 2011 movie, Moneyball, the Oakland A’s needed to do more with their limited budget, so they applied math to their strategy to produce amazing results. While I won’t drop any spoilers, I think it is worthwhile mentioning some MoneyBall principles which directly relate to InfoSec:
- Identify Undervalued Assets (such as skills correlated with winning)
- Challenge Assumptions (such as gathering situational statistics)
- Studying and Learning from Outliers
To drive this home, my presentation outlined how Strong Authentication, Process and Network Statistical Modeling and Honeypots directly applied the principles of MoneyBall to InfoSec.
Strong Authentication has several definitions but I prefer the following: proving you are who you say you are with more than a single factor (such as just a password). A great and forward-looking definition of this term was proposed by Tony Arcieri from Square, “strong something you have + weak something you know”.
Examples of strong authentication were covered including the use of Yubikeys (hardware tokens) and Duo Push Notifications. Both of these solutions are based on a solid foundation of cryptography (math) and the exploitation of intractable problems delivered by one-way functions. Yubikeys and Duo Push Notifications are excellent examples of low friction but high assurance authentication methods making it easier to do the right thing. Yubikeys provide one time passwords (OTPs) as well as support RSA and ECC key pairs. Duo Push Notifications provide out-of-band strong authentication backed by alignment with Mozilla’s TLS intermediary compatibility. This works by using push notifications (such as Apple Push Notification Service) then Duo for the receipt and confirmation. The out-of-band reply is controlled by TLS, HSTS, 2048-bit RSA keys and prioritized AEAD ciphers.
Process and Network Statistical Modeling
Building upon strong authentication, process and network statistical modeling extends the power of existing tools such as an IDS/IPS. Using math, here are some examples of things which can be considered:
- Humans are predictable: The first 5 or 10 minutes after authentication events can reveal some interesting events (for example, if I am an HR professional, it is probably statistically significant if I am running the command prompt and netstat after logging in). Even browser tab positions demonstrate predictable behavior (I like my email tab on the left…if it is on the right, that’s not normal behavior) as does my choice in music (I don’t listen to Country Music—ever).
- Devices and systems are predictable: A network printer should have very simple and well-defined network traffic patterns while immutable architecture shouldn’t change. If a printer is port-scanning the network, that’s a real problem. If a server in an immutable architecture starts a bash shell, that’s an emergency or it’s rogue.
Let’s dive into process predictability. There are some interesting ways to obtain this data including, but not limited to: CarbonBlack, auditd, osquery and Splunk. To demonstrate process-based data, below is a histogram showing command line process execution on my laptop:
- A small number of processes run many times.
- Chrome command line processes change often providing uniqueness as it constantly updates – this is a good thing.
- Love using wc within bash – super useful along with less, cut, sort, uniq, tail….all the usual suspects.
- Operating system components are common and run many times (syncdefaultsd, gssd).
- The test of running dtrace one time is a significant event. There are very few situations where a technical user needs to run dtrace, much less a business user.
If we use a basic recurrence interval, we can estimate the likelihood of an event on my machine:
Now that we have some basic information, we can build a better model if we consider additional factors to put math on our side:
- What if this activity was on a server?
- What if that server is administered via ruthless automation?
- What if that server was part of an immutable architecture?
- What if that server logged in real-time to an intelligent, statistically-driven system?
- What if push notifications are paired with statistics and a bot (like at Slack) to flag activity and educate users?
- What if we use Shannon Entropy calculations for things like DNS queries?
From a technical perspective, we can see how this data can be used to monitor the infrastructure, data stores and networks from a technical perspective – what about applications and business processes?
The last example is a means of gathering high-value data from honeypots. While some alerting systems provide valuable data, the value of that data may not be high given a low signal-to-noise ratio. A goal of honeypots is to enable high-value alerts, even if it’s just a single alert.
A low-value event may be one which is consistently a false positive, take the following, simply put, it allows you to run compiled C from a web server::
2016-09-16 11:17:56 192.168.xxx.xxx tcp 192.168.xxx.xxx:59040 -> 184.108.40.206:80 OS-OTHER Bash CGI environment variable injection attempt (1:31977:5) (+0)
This alert is like an IDS heartbeat. It fires on a predictable and somewhat consistent basis, and while reviewed and acknowledged, it remains a good indicator that the IDS is working as-expected. What if we can implement alerts firing far less, with a much higher value, a higher signal-to-noise ratio? If an adversary probes a fake network file share residing on a high-interaction honeypot, that’s a high value alert.
To close the presentation, we covered the HackingTeam breach which was made public in April of 2016 with an evaluation of opportunities to add math-based defensive measures. Their pastebin dump can be found here and while not covered in this post, it is a very interesting read supporting the below applied techniques.
Applying These Techniques In the Real-World
HackingTeam is an offensive security organization based in Milan, Italy. This is a company of InfoSec experts including the authors of Ettercap: this company did most things right. While attribution has been somewhat unclear, the pastebin blow-by-blow released is academically fascinating. Using the Kill Chain Model from Lockheed-Martin/Leidos, the following covers the phases of the attack and opportunities for math to help:
Data and a value paradox:
Data protection is largely based on devaluation, while working to increase its value when applied to adversaries. High-value data (such as PII, IP, strategy and advanced processes) is protected via forms of devaluation such as encryption, isolation, segmentation, strong authentication, immutable architecture, etc. But what about data in which we should invest, such as network and process data? Investing in and increasing the value of this data can be done using strategies based in math.
Dwolla recognizes that security is never done, but rather, it is a process. The sharing of the Information Security community is part of this process and we are grateful for the opportunity to participate in the SecureIowa conference and more importantly, learn from the presenters and conference attendees.
We'll help you design your ideal payments experience. We’ve sent you a message to kick off the conversation with our team. Please check your inbox. There was an error and the form was not submitted.
Learn more about Dwolla's ACH API
We'll help you design your ideal payments experience.
We’ve sent you a message to kick off the conversation with our team. Please check your inbox.
There was an error and the form was not submitted.