Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
Clear objectives and goals are key to success for any initiative, and AppSec is no exception. But many organizations struggle to establish application security goals or focus on the wrong goals to the detriment of their program. Below, we outline factors to consider when creating goals for your application security program.
At a high level, the goals for your AppSec program should focus on a set of core metrics:
Today, we'll cover some things that you might find quite useful in your everyday work. We'll go through some of the best practices for logging into AWS Lambda, and we will explain how and why these ways will simplify your AWS Lambda logging. Let's start with the basics. What is logging?
AWS Lambda is a service that will automatically monitor Lambda functions for you, and it will report the metrics via Amazon CloudWatch. In order to help you with resolving the function failures, Lambda logs will manage all requests by your function as well as automatically store logs that are generated by your code through Amazon CloudWatch Logs.
When we talk about instrumentation, we’re mainly focused on the OpenTracing API. It was created by industry experts to solve a growing and recognized problem — how to gain visibility into distributed systems. The OpenTracing API is a layer that sits between the origin of the data that we want to gain visibility into (such as the application logic, microservices frameworks, and RPC libraries), and it feeds it to the LightStep tracer system.
To begin instrumentation, we recommend identifying the relevant frameworks. Modern distributed systems consist of large, shared libraries. Often, the OpenTracing community has already provided some helper plugins that can add tracing and instrumentation to these libraries. Anything that can’t be covered with these libraries can be instrumented directly with the OpenTracing API, so there are no gaps in tracing and instrumentation. Finally, we provide the LightStep tracer library in order to send the data to our SaaS backend and present it for analysis.
Predicting failures of software in a production environment is very critical, apart from ensuring the quality during the development stage. The failures can happen in many ways, predicting them upfront and ensuring there are solutions for all such failures is a smart way. It will position you ahead in the race.
The preparation for failure should start from the initial stage of software design and carry on to the development and testing cycles. We must keep questioning our decisions in all these stages about the probability of failures and associated solutions.
We recently re-designed our API Client UI from scratch. In this post, I want to share best practices on handling Access Secrets, and how these influenced our new design.
Every microservice, every front-end, every developer, and whoever else directly accesses your API should get its own API Client. This allows request correlation and the ability to revoke an API Client quickly when you find out it has been leaked. But most importantly, it is the basis for the principle of least privilege.