Information Security

January 10, 2019 By PC Portal

Security newsround: January 2019

We round up interesting research and reporting about security and privacy from around the web. This month: the security year in review, resilience on rails, incidents in depth, phishing hooks millennials, Internet of Threats, and CISOs climbing the corporate ladder.

A look back at cybercrime in 2018

It wouldn’t be a new year’s email without a retrospective on major security incidents over the previous 12 months. Credit to CSO Online for assembling a useful overview of some of last year’s most common risks and threats. To beef up this resource, it sourced external research and stats, while adding plenty of links for further reading. Some of the highlights include the massive rise in cryptocurrency mining. “Coin miners not only slow down devices but can overheat batteries and sometimes render a device useless,” it warned.

The article also advises against posting mobile numbers on the internet, because criminals are finding ways to harvest them for various scams. CSO also advises organisations about knowing the value of their data in order to protect it accordingly. Threatpost has a handy at-a-glance guide to some of the big security incidents from the past year. Meanwhile, kudos to Vice Motherboard for its excellent ‘jealousy list’ which rounds up great hacking and security stories from 2018 that first appeared in other media outlets.

Luas security derails tram website

The new year got off to a bad start for Dublin’s tram operator Luas, after an unknown attacker defaced its website in a security incident. On January 2nd, the Luas site had this message: “You are hacked… some time ago i wrote that you have serious security holes… you didn’t reply… the next time someone talks to you, press the reply button… you must pay 1 bitcoin in 5 days… otherwise I will publish all data and send emails to your users.”

The incident exposed 3,226 user records, and Luas said they belonged to customers who had subscribed to its newsletter. News of the incident spread widely, possibly due to Luas’ high profile as a victim, or because of the cryptocurrency angle.

The tram service itself was not affected, nor was the company’s online payments system. While the website was down, Luas used its Twitter feed to communicate travel updates to the public, and warned people not to visit the site. Interviewed by the Irish Times, Brian Honan said the incident showed that many organisations tend to forget website security after launch. As we’ve previously blogged, it’s worth carrying out periodic vulnerability assessments to spot gaps that an attacker could exploit. With the Luas site not fully back six days later, Brian noted on Twitter that it’s important to integrate incident response with business continuity management.

One hacked laptop and two hundred solemn faces

When an employee of a global apparel company clicked on a link in a phishing email while connected to a coffee shop wifi, they unwittingly let a cybercrime gang onto their corporate network. Once in, the attackers installed Framework POS malware on the company’s retail server to steal credit card details. It’s one real-life example from CrowdStrike’s Cyber Intrusion Casebook. The report details various incident response cases from 2018. It also gives recommendations for organisations on steps to take to protect their critical data better. In addition to coverage in online news reports, the document is available as a free PDF on CrowdStrike’s site.

Examples like these show the need for resilience, which we’ve blogged about before. No security is 100 per cent perfect. But it shouldn’t follow that one gap in the defences brings the entire wall crumbling down.

Digitally savvy, yes. Security savvy, not so much

Speaking of phishing, a new survey has found that digital natives are twice as likely to have fallen victim to a phishing scam than their older – sorry, we mean more experienced – colleagues. Some 17 per cent in the 23-41 age group clicked on a phishing link, compared to 42-53 years old (6 per cent) or 54+ (7 per cent). The findings suggest a gap between perception and reality.

Out of all the age groups, digital natives were the most confident in their ability to spot a scam compared to their senior peers. Yet the 14 per cent of digital natives who weren’t as sure of their ability to spot a phish was strikingly close to the percentage in the same age bracket who had fallen for a phishing email. The survey by Censuswide for Datapac found that 14 per cent of Irish office workers – around 185,000 people – have been successfully phished at some stage.

OWASP’s IoT hit list

Is your organisation planning an Internet of Things project in 2019? Then you might want to send them in OWASP’s direction first. The group’s IoT project aims to improve understanding of the security issues around embedding sensors in, well, anything. To that end, the group has updated its top 10 list for IoT. The risks include old reliables like weak, guessable passwords, outdated components, insecure data transfer or storage, and lack of physical hardening. The full list is here.

The number’s up for CISO promotions

Why do relatively few security professionals ascend to the highest levels of business? That’s the provocative question from Raj Samani, chief scientist with McAfee. In an op-ed for Infosecurity Magazine, Samani argues that security hasn’t yet communicated its value to the business in an identifiable way. Proof of this is the fatigue or indifference over ever-mounting numbers of data breaches. Unlike a physical incident like a car accident where the impact is instantly visible, security incidents don’t have the same obvious cause and effect.

“The inability to determine quantifiable loss means that identifying measures to reduce risk are merely estimated at best. Moreover, if the loss is rarely felt, then the value of taking active steps to protect an asset can simply be overlooked,” Samani writes. “We can either bemoan the status quo or identify an approach that allows us to articulate our business value in a quantifiable way.”

The post Security newsround: January 2019 appeared first on BH Consulting.

March 15, 2018 By PC Portal

AWS Cloud: Proactive Security and Forensic Readiness – part 3

Part 3: Data protection in AWS

This is the third in a five-part blog series that provides a checklist for proactive security and forensic readiness in the AWS cloud environment. This post relates to protecting data within AWS.

Data protection has become all the rage for organisations that are processing personal data of individuals in the EU, because the EU General Data Protection Regulation (GDPR) deadline is fast approaching.

AWS is no exception. The company is providing customers with services and resources to help them comply with GDPR requirements that may apply to their operations. These include granular data access controls, monitoring and logging tools, encryption, key management, audit capability and, adherence to IT security standards (for more information, see the AWS General Data Protection Regulation (GDPR) Center, and Navigating GDPR Compliance on AWS Whitepaper). In addition, AWS has published several privacy related whitepapers, including country specific ones. The whitepaper Using AWS in the Context of Common Privacy & Data Protection Considerations, focuses on typical questions asked by AWS customers when considering privacy and data protection requirements relevant to their use of AWS services to store or process content containing personal data.

This blog, however, is not just about protecting personal data. The following list provides guidance on protecting any information stored in AWS that is valuable to your organisation. The checklist mainly focuses on protection of data (at rest and in transit), protection of encryption keys, removal of sensitive data from AMIs, and, understanding access data requests in AWS.

The checklist provides best practice for the following:

IMPORTANT NOTE: Identity and access management is an integral part of protecting data, however, you’ll notice that the following checklist does not focus on AWS IAM. I have created a separate checklist on IAM best practices here.

Best-practice checklist

1. How are you protecting data at rest?	Define polices for data classification, access control, retention and deletion Tag information assets stored in AWS based on adopted classification scheme Determine where your data will be located by selecting a suitable AWS region Use geo restriction (or geoblocking), to prevent users in specific geographic locations from accessing content that you are distributing through a CloudFront web distribution Control the format, structure and security of your data by masking, making it anonymised or encrypted in accordance with the classification Encrypt data at rest using server-side or client-side encryption Manage other access controls, such as identity, access management, permissions and security credentials Restrict access to data using IAM policies, resource policies and capability policies
2. How are you protecting data at rest on Amazon S3?	Use bucket-level or object-level permissions alongside IAM policies Don’t create any publicly accessible S3 buckets. Instead, create pre-signed URLs to grant time-limited permission to download the objects Protect sensitive data by encrypting data at rest in S3. Amazon S3 supports server-side encryption and client-side encryption of user data, using which you create and manage your own encryption keys Encrypt inbound and outbound S3 data traffic Amazon S3 supports data replication and versioning instead of automatic backups. Implement S3 Versioning and S3 Lifecycle Policies Automate the lifecycle of your S3 objects with rule-based actions Enable MFA Delete on S3 bucket Be familiar with the durability and availability options for different S3 storage types – S3, S3-IA and S3-RR.
3. How are you protecting data at rest on Amazon EBS?	AWS creates two copies of your EBS volume for redundancy. However, since both copies are in the same Availability Zone, replicate data at the application level, and/or create backups using EBS snapshots On Windows Server 2008 and later, use BitLocker encryption to protect sensitive data stored on system or data partitions (this needs to be configured with a password as Amazon EC2 does not support Trusted Platform Module (TPM) to store keys) On Windows Server, implement Encrypted File System (EFS) to further protect sensitive data stored on system or data partitions On Linux instances running kernel versions 2.6 and later, you can use dmcrypt and Linux Unified Key Setup (LUKS), for key management Use third-party encryption tools
4. How are you protecting data at rest on Amazon RDS? (Note: Amazon RDS leverages the same secure infrastructure as Amazon EC2. You can use the Amazon RDS service without additional protection, but it is suggested to encrypt data at application layer)	Use built-in encryption function that encrypts all sensitive database fields, using an application key, before storing them in the database Use platform level encryption Use MySQL cryptographic functions – encryption, hashing, and compression Use Microsoft Transact-SQL cryptographic functions – encryption, signing, and hashing Use Oracle Transparent Data Encryption on Amazon RDS for Oracle Enterprise Edition under the Bring Your Own License (BYOL) model
5. How are you protecting data at rest on Amazon Glacier? (Note: Data stored on Amazon Glacier is protected using server-side encryption. AWS generates separate unique encryption keys for each Amazon Glacier archive, and encrypts it using AES-256)	Encrypt data prior to uploading it to Amazon Glacier for added protection
6. How are you protecting data at rest on Amazon DynamoDB? (Note: DynamoDB is a shared service from AWS and can be used without added protection, but you can implement a data encryption layer over the standard DynamoDB service)	Use raw binary fields or Base64-encoded string fields, when storing encrypted fields in DynamoDB
7. How are you protecting data at rest on Amazon EMR?	Store data permanently on Amazon S3 only, and do not copy to HDFS at all. Apply server-side or client-side encryption to data in Amazon S3 Protect the integrity of individual fields or entire file (for example, by using HMAC-SHA1) at the application level while you store data in Amazon S3 or DynamoDB Or, employ a combination of Amazon S3 server-side encryption and client-side encryption, as well as application-level encryption
8. How are you protecting data in transit?	Encrypt data in transit using IPSec ESP and/or SSL/TLS Encrypt all non-console administrative access using strong cryptographic mechanisms using SSH, user and site-to-site IPSec VPNs, or SSL/TLS to further secure remote system management Authenticate data integrity using IPSec ESP/AH, and/or SSL/TLS Authenticate remote end using IPSec with IKE with pre-shared keys or X.509 certificates Authenticate remote end using SSL/TLS with server certificate authentication based on the server common name(CN), or Alternative Name (AN/SAN) Offload HTTPS processing on Elastic Load Balancing to minimise impact on web servers Protect the backend connection to instances using an application protocol such as HTTPS On Windows servers use X.509 certificates for authentication On Linux servers, use SSH version 2 and use non-privileged user accounts for authentication Use HTTP over SSL/TLS (HTTPS) for connecting to RDS, DynamoDB over the internet Use SSH for access to Amazon EMR master node Use SSH for clients or applications to access Amazon EMR clusters across the internet using scripts Use SSL/TLS for Thrift, REST, or Avro
9. How are you managing and protecting your encryption keys?	Define key rotation policy Do not hard code keys in scripts and applications Securely manage keys at server side (SSE-S3, SSE-KMS) or at client side (SSE-C) Use tamper-proof storage, such as Hardware Security Modules (AWS CloudHSM) Use a key management solution from the AWS Marketplace or from an APN Partner. (e.g., SafeNet, TrendMicro, etc.)
10. How are you ensuring custom Amazon Machine Images (AMIs) are secure and free of sensitive data before publishing for internal (private) or external (public) use?	Securely delete all sensitive data including AWS credentials, third-party credentials and certificates or keys from disk and configuration files Delete log files containing sensitive information Delete all shell history on Linux
11. Do you understand who has the right to access your data stored in AWS?	Understand the applicable laws to your business and operations, consider whether laws in other jurisdictions may apply Understand that relevant government bodies may have rights to issue requests for content, each relevant law will contain criteria that must be satisfied for the relevant law enforcement body to make a valid request. Understand that AWS notifies customers where practicable before disclosing their data so they can seek protection from disclosure, unless AWS is legally prohibited from doing so or there is clear indication of illegal conduct regarding the use of AWS services. For additional information, visit Amazon Information Requests Portal.

For more details, refer to the following AWS resources:

Next up in the blog series, is Part 4 – Detective Controls in AWS – best practice checklist. Stay tuned.

Let us know in the comments below if we have missed anything in our checklist.

DISCLAIMER: Please be mindful that this is not an exhaustive list. Given the pace of innovation and development within AWS, there may be features being rolled out as these blogs were being written . Also, please note that this checklist is for guidance purposes only. For more information, or to request an in-depth security review of your cloud environment, please contact us.

Author: Neha Thethi

Editor: Gordon Smith

The post AWS Cloud: Proactive Security and Forensic Readiness – part 3 appeared first on BH Consulting.

February 27, 2018 By PC Portal

AWS Cloud: Proactive Security and Forensic Readiness – part 2

Part 2: Infrastructure-level protection in AWS

This is the second in a five-part blog series that provides a checklist for proactive security and forensic readiness in the AWS cloud environment. This post relates to protecting your virtual infrastructure within AWS.

Protecting any computing infrastructure requires a layered or defence-in-depth approach. The layers are typically divided into physical, network (perimeter and internal), system (or host), application, and data. In an Infrastructure as a Service (IaaS) environment, AWS is responsible for security ‘of’ the cloud including the physical perimeter, hardware, compute, storage and networking, while customers are responsible for security ‘in’ the cloud, or on layers above the hypervisor. This includes the operating system, perimeter and internal network, application and data.

Figure 1: AWS Defense in Depth

Infrastructure protection requires defining trust boundaries (e.g., network boundaries and packet filtering), system security configuration and maintenance (e.g., hardening and patching), operating system authentication and authorisations (e.g., users, keys, and access levels), and other appropriate policy enforcement points (e.g., web application firewalls and/or API gateways).

The key AWS service that supports service-level protection is AWS Identity and Access Management (IAM) while Virtual Private Cloud (VPC) is the fundamental service that contributes to securing infrastructure hosted on AWS. VPC is the virtual equivalent of a traditional network operating in a data centre, albeit with the scalability benefits of the AWS infrastructure. In addition, there are several other services or features provided by AWS that can be leveraged for infrastructure protection.

The following list mainly focuses on network and host-level boundary protection, protecting integrity of the operating system on EC2 instances and Amazon Machine Images (AMIs) and security of containers on AWS.

The checklist provides best practice for the following:

IMPORTANT NOTE: Identity and access management is an integral part of securing an infrastructure, however, you’ll notice that the following checklist does not focus on the AWS IAM service. I have covered this in a separate checklist on IAM best practices here.

Best-practice checklist

1. How are you enforcing network and host-level boundary protection?	Establish appropriate network design for your workload to ensure only desired network paths and routing are allowed For large-scale deployments, design network security in layers – external, DMZ, and internal When designing NACL rules, consider that it’s a stateless firewall, so ensure to define both outbound and inbound rules Create secure VPCs using network segmentation and security zoning Carefully plan routing and server placement in public and private subnets. Place instances (EC2 and RDS) within VPC subnets and restrict access using security groups and NACLs Use non-overlapping IP addresses with other VPCs or data centre in use Control network traffic by using security groups (stateful firewall, outside OS layer), NACLs (stateless firewall, at subnet level), bastion host, host based firewalls, etc. Use Virtual Gateway (VGW) where Amazon VPC-based resources require remote network connectivity Use IPSec or AWS Direct Connect for trusted connections to other sites Use VPC Flow Logs for information about the IP traffic going to and from network interfaces in your VPC Protect data in transit to ensure the confidentiality and integrity of data, as well as the identities of the communicating parties.
2. How are you protecting against distributed denial of service (DDoS) attacks at network and application level?	Use firewalls including Security groups, network access control lists, and host based firewalls Use rate limiting to protect scarce resources from overconsumption Use Elastic Load Balancing and Auto Scaling to configure web servers to scale out when under attack (based on load), and shrink back when the attack stops Use AWS Shield, a managed Distributed Denial of Service (DDoS) protection service, that safeguards web applications running on AWS Use Amazon CloudFront to absorb DoS/DDoS flooding attacks Use AWS WAF with AWS CloudFront to help protect your web applications from common web exploits that could affect application availability, compromise security, or consume excessive resources Use Amazon CloudWatch to detect DDoS attacks against your application Use VPC Flow Logs to gain visibility into traffic targeting your application.
3. How are you managing the threat of malware?	Give users the minimum privileges they need to carry out their tasks Patch external-facing and internal systems to the latest security level. Use a reputable and up-to-date antivirus and antispam solution on your system. Install host based IDS with file integrity checking and rootkit detection Use IDS/IPS systems for statistical/behavioural or signature-based algorithms to detect and contain network attacks and Trojans. Launch instances from trusted AMIs only Only install and run trusted software from a trusted software provider (note: MD5 or SHA-1 should not be trusted if software is downloaded from random source on the internet) Avoid SMTP open relay, which can be used to spread spam, and which might also represent a breach of the AWS Acceptable Use Policy.
4. How are you identifying vulnerabilities or misconfigurations in the operating system of your Amazon EC2 instances?	Define approach for securing your system, consider the level of access needed and take a least-privilege approach Open only the ports needed for communication, harden OS and disable permissive configurations Remove or disable unnecessary user accounts. Remove or disable all unnecessary functionality. Change vendor-supplied defaults prior to deploying new applications. Automate deployments and remove operator access to reduce attack surface area using tools such as EC2 Systems Manager Run Command Ensure operating system and application configurations, such as firewall settings and anti-malware definitions, are correct and up-to-date; Use EC2 Systems Manager State Manager to define and maintain consistent operating system configurations Ensure an inventory of instances and installed software is maintained; Use EC2 Systems Manager Inventory to collect and query configuration about your instances and installed software Perform routine vulnerability assessments when updates or deployments are pushed; Use Amazon Inspector to identify vulnerabilities or deviations from best practices in your guest operating systems and applications Leverage automated patching tools such as EC2 Systems Manager Patch Manager to help you deploy operating system and software patches automatically across large groups of instances Use AWS CloudTrail, AWS Config, and AWS Config Rules as they provide audit and change tracking features for auditing AWS resource changes. Use template definition and management tools, including AWS CloudFormation to create standard, preconfigured environments.
5. How are you protecting the integrity of the operating system on your Amazon EC2 instances?	Use file integrity controls for Amazon EC2 instances Use host-based intrusion detection controls for Amazon EC2 instances Use a custom Amazon Machine Image (AMI) or configuration management tools (such as Puppet or Chef) that provide secure settings by default.
6. How are you ensuring security of containers on AWS?	Run containers on top of virtual machines Run small images, remove unnecessary binaries Use many small instances to reduce attack surface Segregate containers based on criteria such as role or customer and risk Set containers to run as non-root user Set filesystems to be read-only Limit container networking; Use AWS ECS to manage containers and define communication between containers Leverage Linux kernel security features using tools like SELinux, Seccomp, AppArmor Perform vulnerability scans of container images Allow only approved images during build Use tools such as Docker Bench to automate security checks Avoid embedding secrets into images or environment variables, Use S3-based secrets storage instead.
7. How are you ensuring only trusted Amazon Machine Images (AMIs) are launched?	Treat shared AMIs as any foreign code that you might consider deploying in your own data centre and perform the appropriate due diligence Look for description of shared AMI, and the AMI ID, in the Amazon EC2 forum Check aliased owner in the account field to find public AMIs from Amazon.
8. How are you creating secure custom (private or public) AMIs?	Disable root API access keys and secret key Configure Public Key authentication for remote login Restrict access to instances from limited IP ranges using Security Groups Use bastion hosts to enforce control and visibility Protect the .pem file on user machines Delete keys from the authorized_keys file on your instances when someone leaves your organization or no longer requires access Rotate credentials (DB, Access Keys) Regularly run least privilege checks using IAM user Access Advisor and IAM user Last Used Access Keys Ensure that software installed does not use default internal accounts and passwords. Change vendor-supplied defaults before creating new AMIs Disable services and protocols that authenticate users in clear text over the network, or otherwise insecurely. Disable non-essential network services on startup. Only administrative services (SSH/RDP) and the services required for essential applications should be started. Ensure all software is up to date with relevant security patches For in instantiated AMIs, update security controls by running custom bootstrapping Bash or Microsoft Windows PowerShell scripts; or use bootstrapping applications such as Puppet, Chef, Capistrano, Cloud-Init and Cfn-Init Follow a formalised patch management procedure for AMIs Ensure that the published AMI does not violate the Amazon Web Services Acceptable Use Policy. Examples of violations include open SMTP relays or proxy servers. For more information, see the Amazon Web Services Acceptable Use Policy http://aws.amazon.com/aup/

Security at the infrastructure level, or any level for that matter, certainly requires more than just a checklist. For a comprehensive insight into infrastructure security within AWS, we suggest reading the following AWS whitepapers – AWS Security Pillar and AWS Security Best Practises.

For more details, refer to the following AWS resources:

Next up in the blog series, is Part 3 – Data Protection in AWS – best practice checklist. Stay tuned.

Let us know in the comments below if we have missed anything in our checklist!

DISCLAIMER: Please be mindful that this is not an exhaustive list. Given the pace of innovation and development within AWS, there may be features being rolled out as these blogs were being written . Also, please note that this checklist is for guidance purposes only. For more information, or to request an in-depth security review of your cloud environment, please contact us.

Author: Neha Thethi

Editor: Gordon Smith

The post AWS Cloud: Proactive Security and Forensic Readiness – part 2 appeared first on BH Consulting.