As important as adding new features, app developers need to start placing more emphasis on the security aspect of the applications they design. After all, more app features mean more data residing within an app. Without proper security controls in place, that data can be vulnerable to intruders.
In Part 1, we covered the high-level objectives and methods for attacking service accounts. In Part 2 we discuss defense-in-depth mitigations to those methods. By the end of this blog, you will be able to apply secure-by-default mitigations to threats impacting Snowflake service accounts. The following table from Part 1 highlights the objectives and methods we want to mitigate: These secure-by-default mitigations help prevent and constrain credential misuse from theft and guessing attacks.
Access control is an important function in our daily lives. Access control is provided in many different realms. For example, a physical door, a software program, or an API. Access control simply means that you are controlling who/what can access something. We’re going to focus this discussion around access control for an API. Businesses benefit from providing APIs to their internal (and external) developers.
Open source is great but sometimes it misses the mark for security at enterprise levels. Take Kafka Connect, I’ve built a few connectors in my time and prior to its introduction to Apache Kafka back in 2017 I used other hand cranked pieces of software and security was always a primary concern. One feature that will quickly put a blocker on your project being successful is not reaching production. There’s a number of reasons for this but high up, usually top, is security.
This blog post series will put you in the mind of a defender. In cybersecurity, being a good defender means thinking like an attacker. Part 1 of this blog will focus on understanding why service accounts are excellent targets in the mind of the bad guys, and the threats and attacks a bad guy may use. In Part 2, we’ll lay out how to mitigate the threats and defend against these attacks using the tools Snowflake Cloud Data Platform gives you.
If you have worn the Platform or Security Engineer badge, or if you have a Sec/Ops role, you might have experienced something like this at some point in your career. Hopefully not. You receive a call at 3am, it’s your SOC, something’s not right. Oh sh*t! There’s unidentified traffic on the network from an unknown host and it’s communicating with a remote server. Sounds like a Level 3 exfiltration. It’s gonna be a long night.
Kafka Connect is a great framework for moving data in and out of Kafka. But doing so requires connections with some of your most important data crown jewels. Customer information held in MongoDB, audits in a S3 bucket, payroll information in an Oracle database. Connecting to these data stores requires authentication.
Last week, we announced NSolid 3.11.1, which introduces Role Based Access Control along with support for Node.js Erbium v12.16.2 and Dubnium v10.20.1. You can read here for more information. NodeSource’s Role Based Access Control feature empowers Org Admins to create, define, manage and assign roles that provide access privileges to distinct user-actions and/or views in the NSolid Console and accounts.nodesource.com.
