As a security owner, you need to protect your users against a wide variety of attacks. Many engineers spend a great deal of time focusing on big-picture attacks. They want to answer questions like whether someone has compromised millions of rows in your database, or whether malicious actors have root access to your servers. To your users, smaller-picture threats are just as dangerous.
Recently, we sat down with Dan Robinson, CTO, and Jerry van Leeuwen, DPO, from Heap, to discuss their approaches to security and what they’ve learned as far as security goes throughout their careers. Being able to speak with both of them was great, since Dan brings the executive perspective, and Jerry brings the developer and privacy perspective. We wanted to share the insights that came out of our conversation.
Sqreen is all about application security, and our focus has been on making security transparent and accessible for individual applications. The application was the central actor and everything revolved around it. Maybe you had a single application, or maybe you had a few, but you still reasoned about them separately. As we grow, our clients are increasingly larger, and their infrastructures are more complex.
Earlier today, we introduced a number of very cool features we just released. You can read more about the major items we introduced in our blog post about the launch. In this post, I want to shine some light on one feature in particular: the In-App WAF. I’ll share how we built it, what the process looked like, some of the tradeoffs we made, and more. Long read ahead!
Today is Demo Day at Sqreen, and we’ve rolled out several exciting new features. But before we get into those, I wanted to take a step back and look at why application security needs attention and why the status quo is nowhere near good enough.
In today’s business climate, almost all companies are looking for a way to better leverage software and the power of applications. They’re developing new applications at an increasing pace using the latest technologies. Not only that, but they’re also migrating their older applications, primarily using microservices or cloud computing. But with new technologies and programming languages come increases in security risk. You must be aware of your cybersecurity situation.
If you’re building an application that accepts user or third-party input, a crucial consideration for security is ensuring that you properly validate that input. You want to make sure that any data that enters your application is valid and secure. This data can be anything out of your control, such as comments submitted by users on your website. Input can also come from third-party web services that your application requests (like XML documents).
Sqreen’s Application Security Management platform relies on microagents to leverage the runtime context of applications for security. Our drive when building these agents is to make our protection transparent and as frictionless as possible. The Sqreen agent applies dynamic instrumentation in order to report and protect the application without code modification. We have agents in many languages (and have shared what goes into building them in different languages).
When it came along in the mid-1990s, Java promised a revolution in programming languages. At the time, a great deal of business programming took place in C or C++. Anyone who’s written those languages professionally knows that they can be full of non-obvious pitfalls. Java was a revelation because it removed many of those pitfalls. Instead of worrying about manually allocating and freeing memory, Java did all of that for you.
One of the great things about security is that there is always more to learn. When you’re protecting your applications and users, understanding the kinds of attacks bad actors may attempt can help you get a better sense of how you should protect your applications and the kind of business logic threats you may be exposed to. In this article, we’re going to take a look at timing attacks.
