One way organizations can improve their security and operational ability is to collect logs in a central location. Centralized logging allows engineers across the entire organization to have a “common view” of the system under load, and can provide vital shared context when things go wrong.
Over the last few months, we at Threat Stack have been reworking how we handle all aspects of our logging system. This project encompasses everything, from the content of our log data to the infrastructure that collects it. In this post you’ll learn about how our internal applications send log data, where they send it to, and the trade offs we considered in making our collection system reliable. Read more “Reliable UNIX Log Collection in the Cloud”
In Part 1 of this post we explained how you can find all the secrets in your environment. In Part 2 we will discuss effective ways to store and manage secrets — to keep them from leaking to unauthorized people. Read more “Cloud Security Best Practices: Finding, Securing, & Managing Secrets, Part 2”
parboiled2 is a Macro-Based PEG Parser Generator written in Scala. It has become our preferred tool for creating parsers for simple grammars. It offers a fairly simple syntax for creating parsers and boasts significantly better performance over Scala Combinators.
To illustrate its use, we will use this post to build a parser for a simplified version of the Slack Assisted Search. Read more “Parsing Simple Grammars in Scala With parboiled2”
Test systems are the guts of your overall system design. Test systems embody an incredible amount of the history of how your team’s code and development practices turn into the tools, applications, and services you provide to your users. Most importantly, these systems show how your systems, tools, and applications mature and refine, and every brilliant and embarrassing decision your team made to create your product can often be found there.
But the contents of test environments, whether it’s test frameworks, CSV files, or a rainbow of test data, can be very sensitive, and more importantly, your test systems could contain a decade or more of information related to the development of your systems, tools, and applications. In spite of the potential sensitivity of the data in these systems, the often ad hoc, or ShadowOPS, nature of their development, frequently means that test systems do not undergo the same security scrutiny as other parts of your development environment or production systems, and this means that the risk associated with them probably outstrips the regular investment that has been made to secure them. So from a security point of view, it’s time to right the balance — to toughen up the soft underbelly of your test systems so they don’t undermine your test, dev, and production environments. Read more “Test Systems: The Soft Underbelly of System Security”
I’m a big fan of the YubiKey 4.
The YubiKey is a security device that originally outputted a 44-character “one time password” that could be decoded and mathematically verified and used as a second factor for authentication. Over the last few years, improvements to the devices mean that they can also perform other important functions, such as storing:
- Identity, Signature, and Encryption Certificates
- U2F data for websites (GitHub and GMail, among others, support this)
- GPG Keys
If you’re looking to set this up on your own, read on to learn how this extra functionality helps your security game, and how you can configure services to use it. Read more “Securing User Credentials With the YubiKey 4”
After moving our build infrastructure to webpack, one of the hurdles we had to overcome was finding a good way to run unit tests. Quite a few tutorials and how-tos are available for using mocha with webpack, but none of them gave us all the things we wanted from our test setup.
Therefore, as described below, we defined our requirements for the testing infrastructure and created a setup that enables us to build a test bundle from any number of spec files in a directory, incrementally rebuild on each spec change, and rerun the test suite via mocha on every change. Read more “Unit Testing With Webpack & Mocha”
The cursor blinks steadily as you stare at a line of code that seemingly serves no purpose. You’re trying to fix a bug that is clearly manifested in this code, but you’ve been down this road before. Deleting it seems innocuous, but what if this is the block that sends your Jenga tower of a program crashing down? Your frustration rises as you recall the number of times you’ve asked for time to refactor and improve this project, and now you’re caught between a rock and hard place. As the table you were working at flips over in your episodic rage, you contemplate your next job and what you’ll do differently.
Read more “4 Ways to Make Tech Debt Great Again”
We’ve all been there. You start your pretty new [insert language here] project, with a vow to do things right. You carefully discuss the project structure, you agree on what the database schema will look like, and your unit test coverage is at a staggering 99.8%! “It’s perfect,” you think as you crack that well-deserved beer and watch bits flow happily through your brand new service.
Fast forward six months, and you’re presented with a completely different scene. The latest set of features has wreaked havoc on your precious project. You have files with 500+ lines of code, your coverage has sunk to a barely acceptable 70%, and your list of complaints with every architectural decision you’ve made is growing by the minute. What an idiot past you was! What happened, and how do we fix it? Read more “Too Big to Succeed: Monolithic Madness”
While we have been using Scala for awhile at Threat Stack, we haven’t been overly satisfied with the HTTP servers that we have used. So a few months ago, we audited a number of options and ultimately decided to try out Finch. We chose Finch for its readable and idiomatic API for constructing HTTP endpoints, solid performance, and some other bells and whistles. We also brought in Circe to handle our JSON serialization needs. Circe was a clear pick for its solid performance and generic derivation.
Read more “Ramping up on Finch: Avoiding Common Gotchas”
One of the first things any security practitioner will tell you to do is keep your software up to date. It’s the number one way to protect against exploits targeting known vulnerabilities. In fact, most attacks these days don’t use new or novel attack methods, or even recently discovered vulnerabilities to succeed. They often use vulnerabilities that are years old!
Now while it’s simple to say that everyone should just run the most recent versions of operating systems and packages, actually implementing this quickly becomes painful for a number of reasons.
Read more “Vulnerability Management: Navigating the Deep Dark Pit of Version Numbers”