SSO is an umbrella term for any time a user can login to multiple applications while only authenticating once. It covers both federation and password vaulting which is more commonly known as “Enterprise SSO”. The main difference is that federation eliminates the requirement to use and remember passwords and Enterprise SSO doesn’t. 

‍

Federation allows single sign-on (SSO) without passwords – the federation server knows the username for a Person in each application and presents that application with a token that says, " this Person is domain\johndoe or johndoe@example.com". No password is required for the user to login to each system. Because of the trust between the two systems, the target application accepts this token and authenticates the user. The federation server passes that token using one of the standard identity protocols: SAML, OpenID, WS-Trust, WS-Federation and OAuth. The benefit to federation is security and authentication into both on premise and cloud applications. 

‍

Enterprise SSO is when the applications all still require that a password be sent to login, but the software handles storing it and automatically retrieving it for the user and inputting it into the application for an automatic login. The user still has a password for each system that must be provided to login, must be changed on a regular basis, etc. 

‍

I like analogies; in my mind, Identity federation is like an amusement park. With Enterprise SSO (ESSO), you get into the amusement park but still need a ticket for each ride (think Santa Cruz Beach Boardwalk). With federation, you get into the amusement park but have a wristband that every ride operator recognizes and lets you on (think Disneyland).

Phishing/keyloggers/sniffers 

The simplest way to discover someone’s password is to have them tell you it. This can be done by persuading them to type it into a website you control (commonly known as phishing), by installing a keylogger (either hardware or software) on a computer, or by reading traffic on an unencrypted wireless or wired network. For intruders these methods have the great benefit that it does not matter how long or complex a password the user has chosen: the intruder can simply read it. Cracking of hashes/brute force If the intruder cannot obtain the password then he can simply use a program to generate billions of possible passwords (often using the same techniques as are suggested for choosing passwords) and try each of them against the account. The crudest way to do this is to simply attempt to log in using each generated password: the resulting flood of password failures should be easy for a system administrator to spot, but since attackers continue to use this approach it seems it is still reasonably successful. Attempts may be made against obscure authenticated services, such as SSH and LDAP, to reduce the chances of detection.

‍

Offline cracking 

Brute force attacks are much less obvious if the intruder can obtain a copy of an encrypted password, for example if a system’s password file can be downloaded, if a hash has been included in a public file, or if an unknown machine can join an authentication group. Once the intruder has one or more encrypted passwords he can do the brute force guessing on his own machine (using modern hardware and algorithms this may take only a few minutes for short passwords), or even use a cloud service, and then return to login to the target once the correct password has been discovered. 

‍

Password recovery/reset systems 

An intruder may not need to get the password from the user if he can persuade the authentication system to either mail it to him or change it to something of his choice. Systems to allow the legitimate user to recover or change a password they have forgotten can also let other people do the same. Helpdesk operators need to be particularly careful to check the identity of anyone asking for a password reset. On-line systems that rely on “secret questions” such as “name of first school” or “birthday” are trivial to defeat if that information can be found on a social network. Systems that send reminders to a backup e-mail address or phone number can fail if the user changes address or number allowing the abandoned backup to be registered by someone else. Educated guesswork It should be obvious that the same techniques used to guess the answers to secret questions can also be used to guess passwords. Anything based on something your friends will know, or that is available from a website, is a very poor choice as a password.

‍

Reuse of Passwords 

Most people now have many different accounts on different systems in both their private and work lives. Although best practice is to have a different password for every account, unfortunately it’s much more common to reuse the same password on different services. That means that an organisation doesn’t just have to worry about the above attacks against its own systems, it has to worry about the same attacks on all other systems where the same password has been used. This probably means that an organisation can no longer completely control whether its passwords are secure: it should also develop plans and systems to detect and respond when a password has been compromised. 

Default passwords 

Equipment and software often has standard pre-configured passwords which, of course, are well known to intruders. Such passwords should always be changed, though it can still be hard to find out where they may have been used. A related problem is where a password is set for the user by a local administrator. Unless the user is required to change the password to one that the administrator does not know, doubt can always be raised which of the two people who knew the password was actually logged in and responsible for the account’s activity. If there are reasons that users cannot be forced to change their passwords on first use then procedures need to be carefully designed and followed to ensure that suspicion does not fall on the wrong person. 

Password embedded in code 

Passwords are also sometimes disclosed by being included in scripts or programs. While this may appear an easy way to automate access to an interactive system it carries high risks of disclosure and alternatives should be used wherever possible. If there is no other alternative then the script or program must be very carefully protected against deliberate or accidental access. The worst possible outcome is for a script containing a plaintext password to end up on a public website.

Amazon Elastic Compute Cloud (Amazon EC2) provides scalable computing capacity. You can use EC2 to launch virtual servers that host applications, run on-demand work loads, or extend your data center for your business. These virtual servers are called EC2 instances and come prepackaged with different options for CPU, RAM, storage, network throughput, and more

An elastic network interface (referred to as a network interface in this documentation) is a virtual network interface that you can attach to an instance in a VPC. Network interfaces are available only for instances running in a VPC.

No matter which type of directory you have, the following ports must be open on the primary network interface of all WorkSpaces:

For Internet connectivity, the following ports must be open outbound to all destinations and inbound from the WorkSpaces VPC. You need to add these manually to the security group for your WorkSpaces if you want them to have Internet access.

TCP 80 (HTTP)
TCP 443 (HTTPS)

‍

To communicate with the directory controllers, the following ports must be open between your WorkSpaces VPC and your directory controllers. For a Simple AD directory, the security group created by AWS Directory Service will have these ports configured correctly. For an AD Connector directory, you may need to adjust the default security group for the VPC to open these ports.

• TCP/UDP 53 - DNS
• TCP/UDP 88 - Kerberos authentication
• UDP 123 - NTP
• TCP 135 - RPC
• UDP 137-138 - Netlogon
• TCP 139 - Netlogon
• TCP/UDP 389 - LDAP
• TCP/UDP 445 - SMB
• TCP 1024-65535 - Dynamic ports for RPC

If any security or firewall software is installed on a WorkSpace that blocks any of these ports, the WorkSpace may not function correctly or may be unreachable.

AWS hardware VPN You can create an IPsec, hardware VPN connection between your VPC and your remote network. On the AWS side of the VPN connection, a virtual private gateway provides two VPN endpoints for automatic failover. You configure your customer gateway, which is the physical device or software application on the remote side of the VPN connection

AWS Direct Connect AWS Direct Connect provides a dedicated private connection from a remote network to your VPC. You can combine this connection with an AWS hardware VPN connection to create an IPsec-encrypted connection.

AWS VPN CloudHub If you have more than one remote network (for example, multiple branch offices), you can create multiple AWS hardware VPN connections via your VPC to enable communication between these networks.

Software VPN You can create a VPN connection to your remote network by using an Amazon EC2 instance in your VPC that's running a software VPN appliance. AWS does not provide or maintain software VPN appliances; however, you can choose from a range of products provided by partners and open source communities. 

DNS stands for Domain Name System which is a hierarchical naming system created for translating host names to IP addresses. For example www.google.com translates to 74.125.224.72

A domain name server (or name server) is a computer that houses DNS zones of domain names. This includes A (host) records, CNAME (aliases) records, and MX (mail exchange) records for domain names. Name servers are essentially a piece of the Domain Name System.

SNMP enumeration is the process of using SNMP to enumerate user accounts on a target system. SNMP employs two major types of software components for communication: the SNMP agent, which is located on the networking device, and the SNMP management station, which communicates with the agent.

Almost all network infrastructure devices, such as routers and switches and including Windows systems, contain an SNMP agent to manage the system or device. The SNMP management station sends requests to agents, and the agents send back replies. The requests and replies refer to configuration variables accessible by agent software. Management stations can also send requests to set values for certain variables. Traps let the management station know that something significant has happened in the agent software, such as a reboot or an interface failure. Management Information Base (MIB) is the database of configuration variables that resides on the networking device.

SNMP has two passwords you can use to access and configure the SNMP agent from the management station. The first is called a read community string. This password lets you view the configuration of the device or system. The second is called the read/write community string; it's for changing or editing the configuration on the device. Generally, the default read community string is public and the default read/write community string is private. A common security loophole occurs when the community strings are left at the default settings: a hacker can use these default passwords to view or change the device configuration.

Countermeasures:

The simplest way to prevent SNMP enumeration is to remove the SNMP agent on the potential target systems or turn off the SNMP service. If shutting off SNMP isn't an option, then change the default read and read/write community names.In addition, an administrator can implement the Group Policy security option Additional Restrictions For Anonymous Connections, which restricts SNMP connections.

Prior to testing it's important to determine what parts of the application require authentication and authorization. Security testing should approach the application from both a non-auth and pre-auth perspective. The goal of the non-authenticated assessment is to identify any security risks which are openly exposed by the application. The authenticated assessment is to identify the security risks once a valid user logs in. For an authenticated assessment ensure that the project team provides credentials in advance. 

Browser (e.g. Firefox, Chrome) Manual crawling of the application and support manual testing of the application. Firefox has a number of built-in plugins such as Web Developer and Firebug that can provide easily viewable information on the source including hidden fields and HTML parameters.

Burp Suite Pro Web proxying tool that supports automated crawling, intercept and manipulation of HTTP requests, replay, injections, randomness of session identifiers, etc. The pro version also supports passive and active scanning.

Nikto (Kali distro) Web server vulnerability scanner that can fingerprint the web server and identify any known vulnerabilities with the web server software or installed application components (e.g. Tomcat) residing on the web server.

Nmap (Kali distro) Port scanner that can quickly identify open application ports on the systems as well as fingerprint the services bound to each port. Nmap additionally provides power in the NSE scripts which can probe services for detailed information, e.g. SSL supported ciphers.

Web Inspect Automated vulnerability scanning of web applications and web services. This is particularly useful for large, complex applications.

SQLmap (Kali distro) SQL injection and blind SQL injection tool used to pinpoint and execute proof of concept SQL injections.

Dirbuster (Kali distro) Brute-force directory guessing to find hidden web interfaces (e.g. admin pages, server status pages).

In order to gain better understanding of the risk associated with a vulnerability, one must gather contextual information related to an application's use.

For example, a cross-site scripting (XSS) vulnerability found post-authentication on an internal app accessible to only 10 employees within the organization will have a lower risk of exploitation than a pre-authentication XSS found on an Internet-facing app.

Questions to ask: 

Business Purpose What business function does the application serve? How important is the application to the success of the business' goals?

User Population How many and what type of users are anticipated to use the application?

Data Types What type of data does the application process and/or store? Are there any PII or PCI elements?

Access Roles How many roles does the application offer and to what granularity?

Depth of the Application How many pages/components does the application consist of? [Crawl the application]

Web/application server What web and application server product does the application run on? [Fingerprint the front end]

Back end server Is data stored in a relational database (e.g. SQL) or flat file? [Fingerprint the back end]

You can use public IP addresses, including Elastic IP addresses (EIPs), to give instances in the VPC the ability to both directly communicate outbound to the Internet and to receive unsolicited inbound traffic from the Internet (e.g., web servers).  

Your AWS resources are automatically provisioned in a ready-to-use default VPC. You can choose to create additional VPCs by going to the Amazon VPC page in the AWS Management Console and selecting "Start VPC Wizard".

You’ll be presented with four basic options for network architectures. After selecting an option, you can modify the size and IP address range of the VPC and its subnets. If you select an option with Hardware VPN Access, you will need to specify the IP address of the VPN hardware on your network. You can modify the VPC to add more subnets or add or remove gateways at any time after the VPC has been created.

The four options are:

1. VPC with a Single Public Subnet Only
2. VPC with Public and Private Subnets
3. VPC with Public and Private Subnets and Hardware VPN Access
4. VPC with a Private Subnet Only and Hardware VPN Access

• A Virtual Private Cloud (VPC): A logically isolated virtual network in the AWS cloud. You define a VPC’s IP address space from a range you select.
• Subnet: A segment of a VPC’s IP address range where you can place groups of isolated resources.
• Internet Gateway: The Amazon VPC side of a connection to the public Internet.
• NAT Gateway: A highly available, managed Network Address Translation (NAT) service for your resources in a private subnet to access the Internet.
• Hardware VPN Connection: A hardware-based VPN connection between your Amazon VPC and your datacenter, home network, or co-location facility.
• Virtual Private Gateway: The Amazon VPC side of a VPN connection.
• Customer Gateway: Your side of a VPN connection.
• Router: Routers interconnect subnets and direct traffic between Internet gateways, virtual private gateways, NAT gateways, and subnets.
• Peering Connection: A peering connection enables you to route traffic via private IP addresses between two peered VPCs.
• VPC Endpoint: Enables Amazon S3 access from within your VPC without using an Internet gateway or NAT, and allows you to control the access using VPC endpoint policies.
• Egress-only Internet Gateway: A stateful gateway to provide egress only access for IPv6 traffic from the VPC to the Internet

Wireless access is enabled (and not required)? Wireless access is configured with open access? SSID suppressed/not broadcast? not ideal, will confuse users, hackers can find it.

MAC address filtering? not ideal, can be spoofed

Wireless access point uses WEP? Wireless passphrase is easily-guessable? 

Bluetooth access is enabled (and not required)? Bluetooth pairing is not configured with authentication?

Does the DNS service allow unauthorized zone transfers? Is the DNS service vulnerable to cache poisoning? Does the DNS service allow unauthorized dynamic updates?

Is the system configured for NTP? Is NTP from an authenticated and authorized source?

Is FTP (21/TCP) enabled? Is anonymous FTP login allowed? Is TFTP enabled and not necessary? Is DHCP enabled and not necessary? Is DNS enabled and not necessary? Are unnecessary routing protocols (e.g. BGP, EIGRP, OSPF, RIP, VRRP, GLBP, VTP, DTP) enabled? Are other unnecessary protocols (e.g. echo, finger, chargen) enabled?

Is Telnet (23/TCP) running on the system? Is HTTP login enabled on the system? If HTTPS is enabled, are weak ciphersand protocols suported? If SSH is enabled, is SSHv1 supported? Is SNMP v1 or 2c supported? Is the administrative interface accessible over other clear-text protocols (e.g. rlogin, rsh)?​

Does the application set redirect or forward targets within parameters? Are redirect(s) and forward(s) not validated by the server prior to redirecting the user?

Does the application display to screen full debit or credit card numbers? Does the application store PCI data in an unencrypted format? Does the application transmit PII/PCI data over an unencrypted channel? Does the application display to screen full SSN? Are application tokens or keys hardcoded into source code or HTML source pages? Does the application use weak cryptography (e.g. keys less than128 bits or crypto protocols with known vulnerabilities)?​

Is the web server running outdated or unsupported software? Are built-in accounts still enabled or set with default passwords? Are built-in extraneous features (i.e.debug pages, sample code, demo/test functionality) accessible? Do application error messages reveal stack traces or debug information?​ Does the web server support unnecessary HTTP methods?

Does the application display object references (e.g. acct=100001) in the URL? Can a user access other application functions for which they are not authorized? Are administrative functions directly accessible via direct URI reference?​

Is the application vulnerable to persistent (stored) XSS? Is the application vulnerable to reflected XSS? Is the application vulnerable to Cross-Frame Scripting (XFS)?​

Are session IDs displayed in the URL string? Are session IDs vulnerable to session fixation? Are session IDs predictable? Are session cookies exposed to unauthorized access? Are sessions not properly terminated after a timeout or after a user-initiated termination? Does the application lack a proper logout function?​

​Does the application submit authentication credentials over an unencrypted connection? Does the application store authentication credentials in cleartext or weak format? Do application functions allow for anonymous enumeration of valid user accounts? Does the application allow for caching (i.e. remembering) of a user password?

32-bit OS can only handle up to 4GB RAM. Would be a waste of VM resources. Should be configured with a 64-bit OS.

- Use AWS identity and access management (IAM) to control access to your AWS resources 

- Restrict access by allowing only trusted hosts or networks to access ports on your instance 

- Review the rules in your security groups regularly 

- Only open up permissions that your require 

- Disable password-based login remote logins for root user

​Is the application vulnerable to SQL injection?
command injection?
LDAP injection? ​
XML injection?​

Custom-coded apps (both in-house and 3rd party), commercial of the shelf (COTS) app, web service, thick client/desktop app

Review initial security scoping documents, submitted by the project team, for completeness and accuracy.

Review system requirements packages to ensure that projects address enterprise and compliance requirements, standards, and best practices. 

Review system design packages to assess the proposed system architecture, communication paths, roles, and functionality. Ensure you understand the as-is and to-be states. 

Perform source code review of in-house developed applications to identify vulnerable code. 

Conduct technical security testing of the application or system to identify vulnerabilities and determine risk exposure.

Work with the project team to address outstanding security findings. Complete your review providing a summary of the assessment, findings, mitigations, and recommendation.

Encrypt data at rest and in motion. Encrypting “in motion” is already well known to you – the standards of HTTPS/SSL and IPSEC apply equally well in the data center and in the cloud.

Encrypting “at rest” means that the data must be encrypted when it resides on a disk, in a database, on a file system, in storage, and of course if it is backed up. In the real world, people have not always done this in data centers – often relying on physical security as a replacement. In the cloud, physical security is no alternative – you must encrypt sensitive data.

This actually means data must be encrypted constantly as it is being written, and decrypted only when it is going to be used (i.e. just before a specific calculation, and only in memory). Standards such as Advanced Encryption Standard (AES) are commonly used for data encryption at rest.

The key components of AWS are

Route 53: A DNS web service

Simple E-mail Service: It allows sending e-mail using RESTFUL API call or via regular SMTP

Identity and Access Management: It provides enhanced security and identity management for your AWS account

Simple Storage Device or (S3): It is a storage device and the most widely used AWS service

Elastic Compute Cloud (EC2): It provides on-demand computing resources for hosting applications. It is very useful in case of unpredictable workloads

Elastic Block Store (EBS): It provides persistent storage volumes that attach to EC2 to allow you to persist data past the lifespan of a single 

EC2CloudWatch: To monitor AWS resources, It allows administrators to view and collect key. Also, one can set a notification alarms in case of red flags.

Document a repeatable, comprehensive security testing methodology to evaluate the security controls for various technology types. ​​​This will better assure consistent, accurate testing of systems during the SDLC for projects.

Prior to any security assessment, have the PM/tech lead complete the scoping questionnaire. This will identify all in-scope and out-of-scope technologies and components and will allow the security engineer to estimate the level of effort to complete security testing. The in-scope items in the questionnaire will be reflected in the security test plan and confirmed by the PM/tech lead prior to security testing.