IAM user management strategy
24 Feb 2015 - Loïc Simon
This article is part of the AWS blog post series
Use IAM groups
When granting privileges to IAM users, AWS account administrators should avoid
use of user-specific policies. Instead, create groups whose name explicitly
defines the members' job functions or responsibilities (e.g. AWS
Administrators, Operations, Developers, Accountants), and define the
permissions granted within group policies. Doing so will simplify the
permissions management process as changes in group policies apply to all
When performing AWS configuration reviews, iSEC often discovers IAM users
whose privileges have been granted via a combination of IAM user and IAM group
policies. It is not uncommon to see IAM users who are granted full
administrator privileges in a redundant manner, via both user and group
policies. Such configuration creates an avenue for configuration mistakes, as
another administrator may believe that terminating an IAM user's membership to
the admin group is sufficient. Therefore, banning use of IAM user policies
will result in making one's AWS environment less error-prone.
Note: It is on purpose that iSEC recommends using IAM group names that
reflect a job title or responsibility. IAM users who do not fit in such groups
(e.g. headless users) should not exist. Instead, AWS account administrators
should investigate use of IAM roles for EC2. Further details will be discussed
in an upcoming blog post.
Create a common IAM group to apply generic policies
Because a number of policies must be applied to all users, iSEC recommends that
AWS account administrators create an IAM group that all IAM users belong to.
Doing so will allow AWS account administrators to consistently grant privileges
and enforce a number of rules.
Note: It is important that all IAM users belong to this common IAM group
to ensure that policies are consistently applied. Failure to do so will create
gaps in one's AWS environment security posture.
Authorize IAM users to manage their credentials
To begin with, iSEC recommends that AWS account administrators allow all of
their IAM users to manage their credentials, and only theirs. With all IAM
users belonging to the common IAM group, this can be achieved by applying the
following IAM policy (also available on
to the group.
While the above policy is sufficient to allow users to manage their
credentials, AWS administrators may consider the following statement as an
addition; it allows IAM users to know what the account's password policy is.
The complete JSON payload is available in the AWS-recipes
Use AWS Scout2 to detect user policies
The default ruleset used by AWS
Scout2 includes a rule that checks for
user policies and reports the use of user-specific IAM policies as a warning.
Detection of user-specific IAM policies results in the IAM menu dropdown
containing a "User policies" security risk, as illustrated in the below screenshot.
When clicked-on, this "User policies" link filters the list of IAM users to only
display those who have at least one user policy attached. The orange badge
indicates a warning and the count of user policies attached to this particular
Check that all IAM users belong to the common group
AWS Scout2 comes with a tool — RulesGenerator.py — that allows AWS account
administrators to generate a custom ruleset to tailor the report to their
needs. An optional IAM rule requires all IAM users to belong to a common IAM
group. In order to enable this rule, the following can be done:
- Run the rules generator with the following command line:
./RulesGenerator.py --ruleset_name isec --services iam
- Answer "yes" to the question "Would you like to ensure that all IAM users belong to a given IAM group?"
- Enter the name of your common group (e.g. AllUsers)
- Enter "yes" or "y" to confirm
- Change the level if desired
- Run Scout2
Note: If you have already run Scout2 and do not wish to download the latest
IAM configuration, use the following command to run an offline analysis:
./Scout2.py --ruleset_name isec --services iam --local
The following screenshot illustrates the IAM menu dropdown containing a
security risk when IAM users do not belong to the configured common group.
When clicked-on, this link filters the list of IAM users to only display those
who do not belong to the common IAM group. A colored warning sign appears,
warning about this issue.
Strict management of IAM users and tight control of their privileges is key in
maintaining a secure AWS environment. When followed, the above recommendations
should enable AWS administrators to manage IAM users with improved efficiency
and lower the chances of overly privileged users to exist.
Do not use your AWS root account
23 Feb 2015 - Loïc Simon
This article is part of the AWS blog post series
What is the AWS root account?
The AWS root account is the account that was used — or created — when signing
up with Amazon Web Services. This account has full access to all resources in
the account and it is not possible to alter this configuration.
Risks of using the AWS root account
Using the AWS root account means that there is potential for its compromise.
In particular, iSEC noticed that AWS customers who use the AWS root account
tend to do the following:
- Share credentials between employees.
- Disable Multi-Factor Authentication (MFA) for convenience.
Shared credentials, aside from increasing the risk of compromise during the
sharing process, render credential rotation impractical due to the need for the
newly-generated secret to be known by multiple parties. Sharing the AWS root
account also undermines any effort towards using IAM and leveraging the
fine-grained access controls it offers. Finally, shared credentials result in
loss of the attribution ability, which makes auditing harder and may prevent
AWS Identity and Access Management (IAM)
AWS IAM allows account administrators to create users for every employee and
grant them access to a limited set of services, actions, and resources. This
allows AWS account administrators to apply the principle of least privilege,
which dictates that a given user should only be able to access the information
and resources that are necessary for them to perform tasks they are responsible
for. Additionally, use of IAM allows AWS users to rotate credentials and revoke
privileges without impacting other employees.
AWS account administrators should create an Administrator IAM group, grant
administrator privileges to this group, and create individual IAM users for
each employee in charge of administrating the AWS account. When done, the AWS
root password should be rotated and stored in a safe manner. Furthermore,
additional credentials such as access keys and certificates should be deleted.
Important security consideration about the root account
AWS users should always enable MFA on their root account, even when the
password is securely stored; it is important to realize that the password reset
for the root account process only requires access to the email address
associated with this account. This means that, without MFA, your production
environment is only as secure as an email.
Announcing the AWS blog post series
22 Feb 2015 - Loïc Simon
This article is part of the AWS blog post series
Starting this month, iSEC Partners will start a series of blog posts related to
AWS. The goal of these blog posts will be to:
- Discuss common security gaps in AWS environments
- Discuss common security gaps in the architecture of applications deployed in
- Describe methods and tools used to identify these security gaps
- Share tools and scripts that facilitate daily and secure work with AWS
- Share AWS policies that help improve the security posture of AWS environments
To share material, iSEC created a new public
AWS-recipes repository on
GitHub. The tools and policies shared in this repository will be discussed and
explained in dedicated blog articles.
Because iSEC has been assessing the security of clients' AWS environments for
several years, we have a number of ideas and articles in the pipe awaiting to
be written and published. Without further ado, we will start this series with
articles that discuss Identity and Access Management (IAM) common issues and
best practices, and will present a strategy to improve one's security posture
when using AWS.
CA Alternative Whitepapers
11 Feb 2015 - Braden Hollembaek
Academic co-authors Adam Bates, Joe Pletcher, Tyler Nichols, Dave Tian and
iSEC engineer Braden Hollembaek had a pair of interesting papers published at
the 2014 Conference on Computer and Communications Security and the 2014
Internet Measurement Conference, respectively.
In "Securing SSL Certificate Verification through Dynamic Linking", the paper
introduces CertShim, a lightweight retrofit to existing SSL/TLS
implementations that provides new mechanisms to address: vulnerabilities in
legacy software, improper usage of existing libraries, and the swift
bootstrapping of new enhancements. This is accomplished by dynamically hooking
calls to the certificate validation entry points in the OpenSSL, PolarSSL, and
GnuTLS libraries via an LD_PRELOAD shim. The paper also demonstrates
CertShim's extensibility by adapting it to work with Convergence, DANE, and
Client-Based Key Pinning. CertShim imposes only a modest 20ms overhead for an
SSL verification call and, by coarse estimate, hooks the SSL dependencies of
94% of Ubuntu's most popular packages with no changes necessary to existing
applications. This work creates a framework to help increase the system-wide
security of SSL communications in non-browser software, while simultaneously
reducing the barriers to evaluating and adopting alternative proposals to the
certificate authority system.
For context leading into the second paper, it should be pointed out that in
2011 Moxie Marlinspike proposed a CA alternative, Convergence, that extends
the Network Perspectives system of multi-path probing to perform certificate
verification. Unfortunately, adoption of Convergence and other SSL/TLS trust
enhancements has been slow.
Some adoption concerns are addressed in "Forced Perspectives: Evaluating an
SSL Trust Enhancement at Scale", where the question is asked "What if all
certificates were validated with Convergence?" In this paper, a case study of
deploying Convergence under realistic workloads with a university-wide trace
of real-world HTTPS activity is performed. By synthesizing Convergence
requests, it is possible to effectively simulate perspectives-based
verification on an entire university. The paper demonstrates that, through
local and server caching, a single Convergence deployment can meet the
requirements of millions of SSL flows while imposing under 0.1% network
overhead and requiring as little as 108ms to validate a certificate, making
Convergence a worthwhile candidate for further deployment and adoption.
Links to the papers and source code can be found here:
CertShim Paper: certshim_ccs14.pdf
Source code for CertShim: https://bitbucket.org/uf_sensei/cert-shim
Please keep in mind that CertShim is part of an ongoing research project that
relies on unstable function hooks into version-dependent libraries, and as
such, should not be used as a production security resource.
Forced Perspectives Paper: forced_perspectives_imc14.pdf
Calculating SQL Permissions
09 Feb 2015 - Peter Oehlert
iSEC Partners is happy to announce the availability of a
tool to help those wishing to
better secure their database applications and users. It is a simple command
line tool that can monitor Microsoft SQL Server for a period of query activity
and then return the smallest set of permissions necessary to execute all of
the monitored queries.
Unnecessary permissions granted to users and applications can be a significant
threat if or when those credentials can be used by an attacker. Maybe a
database user who normally only queries a couple of static views leaves their
password on a text file on a laptop that gets compromised. Or perhaps an
application has a SQL Injection flaw allowing nefarious ne'er do wells to
issue arbitrary SQL statements against the database. Both of these cases can
lead to painful breaches where large data sets are exfiltrated, modified or
even just wantonly deleted. The SQL Permissions tool will help determine the
most restrictive set of permissions that are actually needed.
This can be useful for developers of applications, as well as applications
that already exist. The key in any case is to execute all of the logic or
activities that permissions are desired for, as the tool will only calculate a
permission for queries it observes. In some cases, an application developer
could do even better by isolating high risk privileges to a different
components using different database credentials, thereby segregating the risk
that highly privileged operations have. Though the tool cannot help
rearchitect an application, it can provide the list of permissions required
and reviewing the list can provide a useful look at the necessary permissions.
The tool is now open sourced and available on iSEC's
GitHub page. It does not support
every kind of potential SQL Statement that can be executed, but covers the
most common queries used in runtime application scenarios. The tool uses
assemblies only available from SQL Server Profiler, so this will require a SQL
Server version that includes Profiler installed locally, even if using trace
files. Notably, that does not include the SQL Express editions. These
assemblies are not included in the tool, and are not available for
redistribution. It has been tested on SQL Server 2012 and 2014, though it
likely works on other editions as the underlying profiling and tracing
technology has not significantly changed.
Good luck, and have fun locking down everything!