According to the 2015 Verizon Data Breach Investigations Report (DBIR). 98% of attacks are opportunistic in nature, and aimed at easy targets. The report also found that more than 70% of attacks exploited known vulnerabilities that had patches available.

The recent breach at Equifax was caused by a known vulnerability in the popular Struts web framework library, when uploading files. It took Equifax at least two weeks after the attack to discover the data breach and this was almost four months after the exploit had been made public. Automated alerting on known exploits could have prevented this catastrophic security hole.

This post shows an automated way to check your third party library dependencies to ensure your site does not become a victim to these opportunistic attacks.

We will use the dependency checker provided by OWASP. This example shows integration with a Maven build where the check is run against every build during the verify stage. The first run will take a while as it has to download the entire vulnerability database. Subsequent runs will have this cached and so will run much faster.

Maven dependency include:

         <dependency>
            <groupId>org.owasp</groupId>
            <artifactId>dependency-check-maven</artifactId>
            <version>${org.owasp.dependency-check-maven.version}</version>
            <scope>test</scope>
        </dependency>

Maven plugin configuration:

             <plugin>
                <groupId>org.owasp</groupId>
                <artifactId>dependency-check-maven</artifactId>
                <version>3.1.2</version>
                <configuration>
                    <cveValidForHours>12</cveValidForHours>
                    <failBuildOnCVSS>8</failBuildOnCVSS>
                </configuration>
                <executions>
                    <execution>
                        <phase>verify</phase>
                        <goals>
                            <goal>check</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

Maven command to run:

mvn org.owasp:dependency-check-maven:check

Reference

https://www.triology.de/en/blog-entries/automatic-checks-for-vulnerabilities-in-java-project-dependencies

https://jeremylong.github.io/DependencyCheck/dependency-check-maven/index.html

https://www.owasp.org/index.php/OWASP_Dependency_Check

Achieving PCI Compliance can be a rather onerous ongoing commitment. The first thing you will have to show is your architecture in the form of a network diagram together with a data flow diagram showing the routes where credit card data is transmitted. The more complex the architecture the more work involved in making it PCI compliant. So what can you do to mimise the amount of effort? Well your first thought should be around minimising the scope that falls under PCI compliance. This can be done by isolating only the components requried for payments and moving everything else outside of this scope.Once this is done you should then think about how to implement the system that will be in scope for compliance and this is what I want to talk about in this post.

The key to easier PCI compliance of YOUR system is to offload as much as possible to other providers and by other providers I mean Cloud hosting providers like AWS and GCP who’s platforms hare already attained PCI compliance.

In this example I’m going to use AWS. I’m going to compare two architectures, one deploying your application on EC2 instances and the other using Lambda as our serverless facilitator.

Lets take a simple application that takes credit card details from customers over the phone line and uses Paypal payment gateway to process the payment.

High level network diagram

If we ignore the telephony section of the data flow to keep things simple in this illustration then these are the architectures that we have to produce in each case

Traditional Architecture

Network diagram for traditional architecture

AWS Components used

VPC
public subnets
private subnets
Internet gateway
NAT gateway
Two Availability zones
Internet Gateway
Bastion host for SSH
Security groups
ACLs
Route tables
S3 buckets for Cloudwatch logs

Serverless Architecture

Network diagram for serverless architecture

AWS Components used

Lambda (using default VPC)
API gateway
S3 buckets for Cloudwatch logs

It’s pretty clear how much simpler the serverless architecture is.

Next we’ll see how some of the PCI requirements are met by each architecture and especially how must of the compliance responsibility is handed over to AWS when using the serverless solution.

How each architecture meets PCI requirements – traditional versus serverless

PCI requirement	Traditional Architecture	Serverless Architecture
Harden operating system	Hardened AMIs, remove unused applications, lock down ports	No instances (AWS takes care of runtime)
Incoming Firewall	DMZ to prevent unauthorized access, Security Group on VPC	Lambda comes with default VPC
Outoing internet access	Internet gateway, NAT gateway, Security groups and/or ACLs	Default Lambda VPC has outgoining internet access
Do not provide direct access to instances	Use a bastion host to allow SSH access	No Instances, so no SSH required

By going serverless we are able to totally ignore the following requirements:

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Requirement 5: Protect all systems against malware and regularly update anti-virus software or programsg

Category: PCI compliance

Do your dependencies leave you open to attack?