These Cisco Terms of Use (this “Agreement”) between You and Cisco cover Your use of the Software and Cloud Services (“Cisco Technology”) obtained through this site. The Cisco Technology is intended for use by business users. Definitions of capitalized terms are in Section 11.
You agree to be bound by the terms of this Agreement through (a) Your download, installation, or use of the Cisco Technology; or (b) Your express agreement to this Agreement. If You do not have authority to enter into this Agreement or You do not agree with its terms, do not use the Cisco Technology.
Section 2. Using Cisco Technology
2.1 License and Right to Use. Cisco grants You, for Your direct benefit during the Usage Term and for the full scope of Your Entitlement under this Agreement, a non-exclusive, non-transferable (except with respect to Software as permitted under the Cisco Software Transfer and Re-Use Policy) (a) license to use the Software; and (b) right to use the Cloud Services (collectively, the “Usage Rights”).
2.2 Use by Third Parties. You may permit Authorized Third Parties to exercise the Usage Rights on Your behalf, provided that You are responsible for (a) ensuring that such Authorized Third Parties comply with this Agreement; and (b) any breach of this Agreement by such Authorized Third Parties.
2.3 Free Service. Cisco is making this Cisco Technology available to You without charge, up to certain capacity limits as described in Section 10 below, and subject to the terms of this Agreement. You agree that Cisco, in its sole discretion and for any or no reason, may terminate Your Usage Rights (or any part thereof) and that any termination may be without prior notice and without liability to Cisco. Cisco may, for example, suspend or terminate Your Usage Rights if (i) Cisco has reason to believe that You engaged in any fraudulent behaviour as it relates to the Cloud Services, or (ii) You use Cisco Technology beyond Your Entitlement. You are solely responsible for exporting Your customer data from the Cisco Technology prior to termination, and, except as required by law, Cisco will provide You a reasonable opportunity to retrieve such data.
2.4 Upgrades or Additional Copies of Software. You may only use Upgrades or additional copies of the Software beyond Your Entitlement if You have (a) acquired those rights under a support agreement covering the applicable Software; or (b) You have purchased the right to use Upgrades or additional copies separately.
2.5 Interoperability of Software. If required by law and upon Your request, Cisco will provide You with the information needed to achieve interoperability between the Software and another independently created program, provided You agree to any additional terms reasonably required by Cisco. You will treat such information as Confidential Information.
Section 3. Additional Conditions of Use
3.1 Cisco Technology Generally. Unless expressly agreed by Cisco, You may not (a) transfer, sell, sublicense, monetize, or make the functionality of any Cisco Technology available to any third party; (b) use the Software on second hand or refurbished Cisco equipment not authorized by Cisco, or use Software that is licensed for a specific device on a different device (except as permitted under Cisco’s Software License Portability Policy); (c) remove, modify, or conceal any product identification, copyright, proprietary, intellectual property notices or other marks; (d) reverse engineer, decompile, decrypt, disassemble, modify, or make derivative works of the Cisco Technology; or (e) use Cisco Content other than as part of Your permitted use of the Cisco Technology.
3.2 Cloud Services. You will not intentionally (a) interfere with other users’ access to, or use of, the Cloud Service, or with its security; (b) facilitate the attack or disruption of the Cloud Service, including a denial of service attack, unauthorized access, penetration testing, crawling, or distribution of malware (including viruses, trojan horses, worms, time bombs, spyware, adware, and cancelbots); (c) cause an unusual spike or increase in Your use of the Cloud Service that negatively impacts the Cloud Service’s operation; or (d) submit any information that is not contemplated in the applicable Documentation.
3.3 Evolving Cisco Technology. Cisco may: (a) enhance or modify the features, functionality, and capacity limits of this Cisco Technology at any time, in its sole discretion, without liability; and (b) perform scheduled maintenance of the infrastructure and software used to provide the Cloud Service, during which time You may experience some disruption to that Cloud Service. Whenever reasonably practicable, Cisco will provide You with advance notice of such maintenance. You acknowledge that, from time to time, Cisco may need to perform emergency maintenance without providing You advance notice, during which time Cisco may temporarily suspend Your access to, and use of, the Cloud Service.
Cisco reserves the right (a) to end the life of this Cisco Technology, including component functionality, (“EOL”), and/or (b) to incorporate all or some of the features and functionality of this Cisco Technology into a Cisco paid offer at any time, in its sole discretion, and without liability (“Cisco Offering”). Any new Cisco Offering will be subject to its own terms and conditions.
3.4 Protecting Account Access. You will keep all account information up to date, use reasonable means to protect Your account information, passwords and other login credentials, and promptly notify Cisco of any known or suspected unauthorized use of or access to Your account.
3.5 Use with Third-Party Products. If You use the Cisco Technology together with third-party products, such use is at Your risk. You are responsible for complying with any third-party provider terms, including its privacy policy. Cisco does not provide support or guarantee ongoing integration support for products that are not a native part of the Cisco Technology.
3.6 Open Source Software. Open source software not owned by Cisco is subject to separate license terms as set out at www.cisco.com/go/opensource. The applicable open source software licences will not materially or adversely affect Your ability to exercise Usage Rights in applicable Cisco Technology.
Section 4. Confidential Information and Use of Data
4.1 Confidentiality. Recipient will hold in confidence and use no less than reasonable care to avoid disclosure of any Confidential Information to any third party, except for its employees, affiliates, and contractors who have a need to know (“Permitted Recipients”). Recipient: (a) must ensure that its Permitted Recipients are subject to written confidentiality obligations no less restrictive than the Recipient’s obligations under this Agreement, and (b) is liable for any breach of this Section by its Permitted Recipients. Such nondisclosure obligations will not apply to information that: (i) is known by Recipient without confidentiality obligations; (ii) is or has become public knowledge through no fault of Recipient; or (iii) is independently developed by Recipient. Recipient may disclose Discloser’s Confidential Information if required under a regulation, law or court order provided that Recipient provides prior notice to Discloser (to the extent legally permissible) and reasonably cooperates, at Discloser’s expense, regarding protective actions pursued by Discloser. Upon the reasonable request of Discloser, Recipient will either return, delete or destroy all Confidential Information of Discloser and certify the same.
4.2 How We Use Data. Cisco will access, process and use data in connection with Your use of the Cisco Technology in accordance with applicable privacy and data protection laws. For further detail, please visit Cisco’s Security and Trust Center.
4.3 Notice and Consent. To the extent Your use of the Cisco Technology requires it, You are responsible for providing notice to, and obtaining consents from, individuals regarding the collection, processing, transfer and storage of their data through Your use of the Cisco Technology.
Section 5. Ownership
Except where agreed in writing, nothing in this Agreement transfers ownership in, or grants any license to, any intellectual property rights. You retain any ownership of Your content and Cisco retains ownership of the Cisco Technology and Cisco Content. You acknowledge and agree that any questions, comments, suggestions, ideas, feedback or other information about this Cisco Technology provided by You to Cisco (“Feedback”) are non-confidential and Cisco may use any Feedback You provide in connection with Your use of the Cisco Technology as part of its business operations without acknowledgment or compensation to You.
Section 6. Warranties and Representations
To the extent allowed by applicable law, Cisco expressly disclaims all warranties and conditions of any kind, express or implied, including without limitation any warranty, condition or other implied term as to merchantability, fitness for a particular purpose or non-infringement, or that the Cisco Technology will be secure, uninterrupted or error free. If You are a consumer, You may have legal rights in Your country of residence that prohibit the limitations set out in this Section from applying to You, and, where prohibited, they will not apply
Section 7. Liability
Neither party will be liable for indirect, incidental, exemplary, special, or consequential damages; loss or corruption of data or interruption or loss of business; or loss of revenues, profits, goodwill, or anticipated sales or savings. The maximum aggregate liability of each party under this Agreement is limited to $5,000 USD. These limitations of liability do NOT apply to liability arising from (a) Your breach of Sections 2.1 (License and Right to Use), 3.1 (Cisco Technology Generally), 3.2 (Cloud Services) or 9.7 (Export). These limitations of liability apply whether the claims are in warranty, contract, tort (including negligence), infringement, or otherwise, even if either party has been advised of the possibility of such damages. Nothing in this Agreement limits or excludes any liability that cannot be limited or excluded under applicable law. These limitations of liability are cumulative and not per incident.
Section 8. Termination and Suspension
8.1 Suspension. Cisco may immediately suspend Your Usage Rights if You breach Sections 2.1 (License and Right to Use), 3.1 (Cisco Technology Generally), 3.2 (Cloud Services) or 9.7 (Export).
8.2 Termination. Cisco, in its sole discretion and for any or no reason, may terminate Your access to this Cisco Technology or any part thereof and any termination may be without prior notice and without liability to Cisco. Cisco may, for example, suspend or terminate Your access immediately if You breach Sections 2.1 (License and Right to Use), 3.1 (Cisco Technology Generally), 3.2 (Cloud Services), or 9.7 (Export). Upon termination of this Agreement, You must stop using the Cisco Technology and destroy any copies of Software and Confidential Information within Your control.
Section 9. General Provisions
9.1 Survival. Sections 4 (Confidential Information and Use of Data), 5 (Ownership), 7 (Liability), 8 (Termination and Suspension), and 9 (General Provisions) survive termination or expiration of this Agreement.
9.2 Third-Party Beneficiaries. This Agreement does not grant any right or cause of action to any third party.
9.3 Assignment and Subcontracting. Except as set out below, neither party may assign or novate this Agreement in whole or in part without the other party’s express written consent. Cisco may (a) by written notice to You, assign or novate this Agreement in whole or in part to an Affiliate of Cisco, or otherwise as part of a sale or transfer of any part of its business; or (b) subcontract any performance associated with the Cisco Technology to third parties, provided that such subcontract does not relieve Cisco of any of its obligations under this Agreement.
9.4 U.S. Government End Users. The Software, Cloud Services and Documentation are deemed to be “commercial computer software” and “commercial computer software documentation” pursuant to FAR 12.212 and DFARS 227.7202. All U.S. Government end users acquire the Cisco Technology and Documentation with only those rights set forth in this Agreement. Any provisions that are inconsistent with federal procurement regulations are not enforceable against the U.S. Government
9.5 Modifications to this Agreement. Cisco may change this Agreement or any of its components by updating it on Cisco.com and/or the Documentation page, which can be found at https://community.cisco.com/. Cisco will exercise commercially reasonable efforts to provide notice of any material changes to this Agreement, and within three (3) business days of posting changes to this Agreement, they will be binding. If you do not agree with the changes, you must discontinue using the Cisco Technology at that time. If you continue using the Cisco Technology after that time, you will be deemed to have accepted the changes to this Agreement.
9.6 Compliance with Laws. Each party will comply with all laws and regulations applicable to their respective obligations under this Agreement. Cisco may restrict the availability of the Cisco Technology in any particular location or modify or discontinue features to comply with applicable laws and regulations.
If You use the Cisco Technology in a location with local laws requiring a designated entity to be responsible for collection of data about individual end users and transfer of data outside of that jurisdiction (e.g., Russia and China), You acknowledge that You are the entity responsible for complying with such laws.
9.7 Export. Cisco’s Software, Cloud Services, products, technology, and services (collectively the “Cisco Products”) are subject to U.S. and local export control and sanctions laws. You acknowledge and agree to the applicability of and Your compliance with those laws, and You will not receive, use, transfer, export, or re-export any Cisco Products in a way that would cause Cisco to violate those laws. You also agree to obtain any required licenses or authorizations
9.8 Governing Law and Venue. This Agreement, and any disputes arising from it, will be governed exclusively by the applicable governing law below, based on Your primary place of business (or primary residence, if you are not a business) and without regard to conflicts of laws rules or the United Nations Convention on the International Sale of Goods. The courts located in the applicable venue below will have exclusive jurisdiction to adjudicate any dispute arising out of or relating to the Agreement or its formation, interpretation or enforcement. Each party hereby consents and submits to the exclusive jurisdiction of such courts. Regardless of the below governing law, either party may seek interim injunctive relief in any court of appropriate jurisdiction with respect to any alleged breach of Cisco’s intellectual property or proprietary rights
Your Primary Place of Business Governing Law Jurisdiction and Venue
Any location not specified below
| State of California, United States of America | Superior Court of California, County of Santa Clara and Federal Courts of the Northern District of California
| Australia | Laws of the State of New South Wales, Australia | State and Federal Courts of New South Wales |
| Canada | Province of Ontario, Canada | Courts of the Province of Ontario |
| China | Laws of the People’s Republic of China | Hong Kong International Arbitration Center |
| Europe (excluding Italy), Middle East, Africa, Asia (excluding Japan and China), Oceania (excluding Australia) | Laws of England | English Courts |
| Italy | Laws of Italy | Court of Milan |
| Japan | Laws of Japan | Tokyo District Court of Japan |
| United States, Latin America or the Caribbean | State of California, United States of America | Superior Court of California, County of Santa Clara and Federal Courts of the Northern District of California |
If You are a United States public sector agency or government institution located in the United States, the laws of the primary jurisdiction in which You are located will govern this Agreement and any disputes arising from it. For U.S. Federal Government users, this Agreement will be controlled and construed under the laws of the United States of America.
9.9 Notice. Any notice delivered by Cisco to You under this Agreement will be delivered on Cisco.com. Notices to Cisco should be sent to Cisco Systems, Inc., Office of General Counsel, 170 West Tasman Drive, San Jose, CA 95134.
9.10 Force Majeure. Neither party will be responsible for failure to perform its obligations due to an event or circumstances beyond its reasonable control.
9.11 No Waiver. Failure by either party to enforce any right under this Agreement will not waive that right.
9.12 Severability. If any portion of this Agreement is not enforceable, it will not affect any other terms.
9.13 Entire agreement. This Agreement is the complete agreement between the parties with respect to the subject matter of this Agreement and supersedes all prior or contemporaneous communications, understandings or agreements (whether written or oral).
9.14 Translations. Cisco may provide local language translations of this Agreement in some locations. You agree that those translations are provided for informational purposes only and if there is any inconsistency, the English version of this Agreement will prevail.
9.15 Order of Precedence. If there is any conflict between this Agreement and any Cisco policies expressly referenced in this Agreement, the order of precedence is: (a) this Agreement; then (b) any applicable Cisco policy expressly referenced in this Agreement.
9.16 Language Election for Purchasers in Quebec. You confirm Your Agreement that this Cisco Technology is currently provided in English only.
Section 10. Additional Terms
10.1 Restrictions on Use by Minor Children. This Cisco Technology is not intended for use by persons younger than the age of consent in their relevant jurisdiction (e.g.,13 years old in the United States under the US Children’s Online Privacy Protection Act of 1998, or 16 or 13 years old in the European Union as per Member State law) (“Minor Children”). Minor Children are not permitted to create an account and You will not authorize Minor Children to access the Cisco Technology.
10.2 Capacity Restrictions. Your right to access and use this Cisco Technology is currently limited to five (5) nodes dedicated to applications/microservices.
10.3 Limited Community Support. This Cisco Technology is provided on a free-of-charge basis, as-is, and without support. Cisco has no obligation to maintain, repair, or upgrade this Cloud Service and Cisco will not provide user support services in connection with this Cisco Technology. User can refer to self-service help materials that cover a range of topics or reach out to our community forum to engage in community support discussions on our Documentation page at https://community.cisco.com/. Cisco makes no representations about and has no liability for these community support resources. All use of these resources, and the advice and guidance therein, is at Your own risk.
10.4 No Competitive Analysis. By agreeing to these terms, You represent and warrant that you will not use this Cisco Technology or its Documentation to (a) copy ideas, features, functions, or graphics; (b) develop competing products or services; or (c) perform competitive analyses.
10.5 Beta Functionality. User acknowledges and agrees that all or some components or functionality of the Cisco Technology may be in beta stage and may not have been (and may not become) productized or commercialized. You acknowledge that Your use and evaluation of this Cisco Technology is at Your own risk.
Section 11. Definitions
“Affiliate” means any corporation or company that directly or indirectly controls, or is controlled by, or is under common control with the relevant party, where “control” means to: (a) own more than 50% of the relevant party; or (b) be able to direct the affairs of the relevant party through any lawful means (e.g., a contract that allows control).
“Authorized Third Parties” means Your Users, Your Affiliates, Your third-party service providers, and each of their respective Users, permitted to access and use the Cisco Technology on Your behalf as part of Your Entitlement.
“Cisco” “we” “our” or “us” means Cisco Systems, Inc. or its applicable Affiliate(s).
“Cisco Content” means any (a) content or data provided by Cisco to You as part of Your use of the Cisco Technology and (b) content or data that the Cisco Technology generates or derives in connection with Your use. Cisco Content includes geographic and domain information, rules, signatures, threat intelligence, and data feeds, and Cisco’s compilation of suspicious URLs.
“Cloud Service” means the Cisco hosted software-as-a-service offering or other Cisco cloud-enabled feature described in this Agreement. Cloud Services include applicable Documentation and may also include Software.
“Confidential Information” means non-public proprietary information of the disclosing party (“Discloser”) obtained by the receiving party (“Recipient”) in connection with this Agreement, which is (a) conspicuously marked as confidential or, if verbally disclosed, is summarized in writing to the Recipient within a reasonable time period after disclosure and marked as confidential; or (b) is information which by its nature should reasonably be considered confidential whether disclosed in writing or verbally.
“Delivery Date” means the date on which the Cloud Service is made available for Your use or, when Usage Rights in Software and Cloud Services are granted together, the earlier of the date Software is made available for download, or the date on which the Cloud Service is made available for Your use.
“Documentation” means the technical specifications and usage materials officially published by Cisco or available on https://community.cisco.com/ specifying the functionalities and capabilities of the applicable Cisco Technology.
“Entitlement” means the specific metrics, duration, and quantity of Cisco Technology that You acquire from Cisco under this Agreement.
“Software” means the Cisco computer programs including Upgrades, firmware and applicable Documentation.
“Upgrades” means all updates, upgrades, bug fixes, error corrections, enhancements and other modifications to the Software.
“Usage Term” means the period commencing on the Delivery Date and continuing until expiration or termination of the Entitlement, during which period You have the right to use the applicable Cisco Technology.
“User” means the individuals (including contractors or employees) permitted to access and use the Cisco Technology on Your behalf as part of Your Entitlement.
“You” means the individual or legal entity using the Cisco Technology.
NEW Cloud Security Academy Level up your skills with hands-on lessons. Get started
In the first entry in this series, we explored what Endpoint Detection and Response (EDR) is, and why the Panoptica Office of the CISO uses it to secure our Amazon EC2 server estate. We previously provided scripts and a basic walkthrough of the installation and configuration of the Microsoft Defender for Endpoint (MDE) Linux sensors. In this entry, we will build on that by exploring Amazon EC2 Image Builder and teaching you how to automate the creation of images with MDE pre-installed on them.
On EC2 Image Builder
Amazon EC2 Image Builder (EC2IB) is a managed service to automate the creation of Amazon Machine Images (AMIs) for Amazon EC2 instances and Docker container images. At Panoptica, we use EC2IB to create (or "bake") "golden" Images. A golden AMI can be thought of as a secure and properly configured baseline you use to create other AMIs or one you use right away. As mentioned in the previous entry, we use EC2 solely as a host for Kubernetes and Container orchestration - so we can use them as-is. What constitutes a "golden" AMI depends on your business and technical requirements but generally includes the latest Version of an Operating System (OS) that you use, complete with all the latest (at build time) updates, patches, and upgrades. It typically includes your absolute baseline requirements - software dependencies, middleware, required Agents, and other security configuration settings such as STIG or CIS hardening. Given that we use them for Kubernetes and containers, the apps will be bootstrapped after we provision the hosts. Still, other teams may act similarly, installing middleware and other components after they launch the Instance.
The reason to use EC2IB versus more "traditional" approaches including using Hashicorp's Packer or creating your own AMI baking pipelines using other AWS services such as EC2 APIs (for Snapshotting and Creating/Sharing AMIs), AWS Lambda, or AWS Systems Manager Automation, and others is to limit the number of moving parts and maintenance. Regardless of the simplicity, all scripts require some form of human capital for management, upgrades, bug fixes, and otherwise. EC2IB eliminates our requirement to maintain these "homebrewed" options, forgoes the reliance on third-party software (Packer), and adopts a more cloud-native and secure approach that abstracts all pieces into baking sharing AMIs on AWS.
For this blog entry, we won't be providing the AWS CloudFormation templates we use to build the required EC2 Image Builder dependencies such as Recipes and Components. Instead, we will use the CLI. Before getting too far ahead of ourselves, EC2 Image Builder contains the following concepts to understand the flow. A Pipeline refers to an end-to-end automation solution that will create a new AMI from a specific Recipe where that Recipe is a collection of various Components. Components are essentially mini-scripts that are provided by AWS, and you can author yourself, which provide various functionality and customization - from applying CIS hardening to installing specific software packages. At least one Component is needed for the Recipe. These are bundled with Infrastructure Configurations which instruct the EC2IB underlying infrastructure that the Recipe will be executed on and finally, Distribution Settings which instructs your Pipeline to place the final product in specified Regions and Accounts.
Distribution Settings do leave a lot to be desired, they're excellent for specifying Regions you want the Image present in, such as any active Regions for your Product as well as any "disaster recovery" Regions. However, Distribution Settings become incredibly verbose when being defined in the CLI or Infrastructure-as-Code (IaC) templates such as AWS CloudFormation. While sharing with specific AWS Accounts is also possible - it does not scale well for multiple Accounts as it does not yet (at the time of this writing) support AWS Organizations IDs. We will use further downstream API calls and automation with other AWS APIs to share these Organizations-wide.
Prerequisites
Access to an S3 Bucket to which you can upload files
AWS CLI installed and configured
IAM Permissions that give Create, Read and Delete permissions for IAM, EC2 Image Builder, S3, EC2, and Systems Manager
Access to an Ubuntu OS (or knowledge to adapt example commands to your preferred OS)
Bootstrapping EC2 Image Builder
We must first create a simple component that will perform basic upgrades and install the dependencies needed for MDE. In a production setting we'd have several Components which would perform CIS Hardening, install additional Agents (such as Application Performance Monitoring), install specific binaries, and so on - we will skip these steps and instead concentrate on MDE as well as the AWS Systems Manager (SSM) Agent, which is required for secure access via Session Manager and other operational automation (patching, configuration, compliance). Feel free to inject your own Components throughout the process.
Before creating the Components, we need to create a YAML document and upload it to an S3 Bucket we have access to. We will reference the URI of this S3 Object (the Component YAML) when passing the CLI command. Create a YAML file (such as mde_comp.yaml) and upload it to an S3 Bucket with the following command.
Note: Ensure you replace $MY_BUCKET with a name of an S3 Bucket to which you have access
Once uploaded, use the following commands to create an EC2IB Component with your CLI.
Note: Ensure you replace $MY_BUCKET with a name of an S3 Bucket to which you have access.
aws imagebuilder create-component \
--name InstallMDEUbuntu \
--semantic-version 1.0.0 \
--description 'Install Microsoft Defender for Endpoint without configuration' \
--change-description 'Install Microsoft Defender for Endpoint without configuration - First Version' \
--platform Linux \
--supported-os-versions Ubuntu 20 \
--uri s3://$MY_BUCKET/mdatp/mde_comp.yaml
After your Component has been created, copy down the ARN attributed to it. When creating your EC2IB Recipe you must choose a base, just like a food recipe you must start with something to build flavors - such as sauteed onions, garlic, ginger, and tomato paste for a Chicken Tikka Masala - it is similar to EC2IB. We will have to start with a parent Image. AWS provides automated population options within the Console to pick AWS-managed instances, but you can also use the ARN of another EC2IB Image you have created or the ARN of any other AMI that to which you have access. There are some other important considerations to keep in mind when specifying a parent image:
Image Operation Systems (OS) must be an EC2IB supported OS, such as Amazon Linux 2, Windows Server 2012R2, and more listed here.
Images must have the AWS Systems Manager (SSM) Agent installed if you will be performing remote access using Session Manager or patching with Patch Manager.
If you specify an AMI by its ARN, the upstream AMI must have the policy to allow the Image to be shared.
If you specify an AMI by its ID, you must be in the same Region and the upstream AMI must have the policy to allow the Image to be shared.
For our purposes, we will use Ubuntu 21.10 which is an interim release before Ubuntu 22.04 LTS is released in 2022. This ensures that OS dependencies such as the versions of Bash, Python, Apt, and other components can be upgraded to their latest versions and reduce the attack surface of your EC2 Image by reducing subsequent vulnerabilities and weaknesses. Having used MDE's vulnerability assessment (as well as Wazuh and Qualys) with Ubuntu 18.04LTS and 20.04LTS images supplied by AWS, there are several hundreds of vulnerabilities present, with a decent amount exploitable - using 21.10 will eliminate a lot of these while (hopefully) maintaining compatibility with applications you built on top of those versions.
In the console, Ubuntu 21.10 is not a native option. The way to get around this is by using a Public AWS SSM Parameter. SSM Parameters are value storage objects that can contain simple strings, integers, or complex objects such as JSON documents and can be used to inject variables or store secret values such as database passwords or API keys. AWS maintains "latest" Parameter namespaces that contain the latest AMI ID for specific architectures and OS's such as the latest Amd64 EBS gp2-based image for Ubuntu 21.10 with the following parameter: /aws/service/canonical/ubuntu/server-minimal/21.10/stable/current/amd64/hvm/ebs-gp2/ami-id. AWS has similar Parameters for Amazon Linux 2, Windows, and other OS versions too which you can easily view in the AWS SSM Parameter Store console as shown below (FIG. 1).
Figure 1 - Public SSM Parameters
Note: When using a "custom" parent image (e.g., not an AWS-managed option) EC2IB will not "sync" with the upstream images for the purpose of re-build automation. You will need to manually update and re-run pipelines periodically as the latest Image updates.
We will resolve this Parameter, save it as an environment variable, and inject it into our Recipe to use as the parent Image. First, save the resolved AMI ID (ami-001844416bebc3258 at the time of this writing) as an environment variable and check it with the following commands.
Note: You may need to install jq, command provided in case it is not installed or has not been updated. You will also need to set your aws configure output to json or replace all jq references with the AWS CLI --query flag.
The AWS SSM CLI command get-parameter will provide a raw payload such as the name, type of parameter, version number, and other details. Therefore, we will use jq to parse the specific value \ that we need. We use the --raw-output flag purposely to ensure we do not get a JSON value \ back (between quotations) for the parameter. Now we are ready to create our first Recipe with the AMI set. We will be using a "JSON skeleton" for this CLI command due to the mildly complex structure that is easier to write in JSON.
Note: Ensure you change $MY_REGION to your AWS Region and change the value for $MY_ACCOUNT to your AWS Account. You can dynamically set that Account variable with the following command: export MY_ACCOUNT=$(aws sts get-caller-identity | jq .Account --raw-output)
There are a few things to note with this CLI JSON skeleton. We provided AWS-managed Components, which will perform installations and configurations of the AWS CLIv2 and install Microsoft Defender for Endpoint and its required dependencies, but it will not configure it. Components are running in the order that they are provided, if you ever had cross-component dependencies, ensure they are in the right order. Additionally, we had to override the default for uninstallAfterBuild which would remove the SSM Agent. We want to keep it so we can automate patching and configuration compliance monitoring with AWS SSM State Manager and Patch Manager.
Lastly, we provide the baseline root volume EBS configuration. We can specify encryption settings and per-volume metadata such as IOPS, Throughput, Storage, and device name which will vary by the Type of EBS Volume we choose. In our case, we will not specify Encryption settings, the default settings will use an AWS-managed Key Management Service (KMS) Customer Masker Key (CMK) which is Regionally-bound and Account-unique and cannot be shared, this will prevent images from being shared. You can technically create a customer-managed KMS CMK that has a Key Policy that allows your entire AWS Organization (or specific Accounts or IAM Principals) to use the Key, but that is beyond the scope of this entry.
Note: When you reference the semantic Version of an AWS-managed Component as x.x.x it will resolve the latest Version of the Component.
To create the EC2IB Recipe, issue the following command from the directory you used to create the JSON document in the previous step.
Ensure you copy the ARN of your Recipe as we will need it in a future step when we create our Pipeline. The next piece we need to create is the Infrastructure Configuration which instructs EC2IB what type of EC2 instance you want to build on (e.g., m5.large or t3.small), network and security details, and most importantly, an IAM Instance Profile which gives your instance permissions to execute the Components and Tests within. In the next steps, we will create a sample Role that has the minimum necessary permissions for EC2IB to use. If you have already used EC2IB in the past, you should already have a Role create likely named "EC2InstanceProfileForImageBuilder", and you can skip the next few steps.
First, let's create a Trust Policy JSON document which will be passed to the CLI command to create an IAM Role. The Trust Policy is what is passed to the "Assume Role Document" part of an IAM Role, it "trusts" other AWS service principals, other AWS accounts, or federated identities – in our case we must trust the Amazon EC2 service principal to use this Role as part of an Instance Profile.
Create the IAM Role and pass the Trust Policy JSON document to it as an argument as shown below.
aws iam create-role \
--role-name EC2IBRole \
--description 'Provides minimum necessary permissions to EC2 Image Builder for usage in Image Pipelines' \
--path '/' \
--assume-role-policy-document file://trust-policy.json
Issue the following commands to attach the required AWS Managed Policies to your newly created IAM Role, these are required by EC2IB for EC2 AMI creation.
aws iam attach-role-policy \
--role-name EC2IBRole \
--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
aws iam attach-role-policy \
--role-name EC2IBRole \
--policy-arn arn:aws:iam::aws:policy/EC2InstanceProfileForImageBuilder
Now create an Instance Profile which we will assign to our previously created IAM Role. You should wait at least a second between issuing commands due to eventual consistency issues which can crop up with the IAM APIs.
aws iam create-instance-profile --instance-profile-name EC2IBInstanceProfile
sleep 1
aws iam add-role-to-instance-profile \
--instance-profile-name EC2IBInstanceProfile \
--role-name EC2IBRole
Now that the Instance Profile has been created, you will need to collect the following details and replace the placeholder variable provided in parentheses after it. A Subnet with connectivity to the internet ($MY_SUBNET) and a Security Group which at least allows HTTPS (TCP 443) traffic ($MY_SGID) are required. Ensure you keep the quotations as they're needed for the JSON document.
Note: This is an abbreviated configuration and leaves out IMDSv2 and Logging configurations, but purposely does not specific an EC2 Key Pair as any failures will cause the EC2IB infrastructure to self-destruct.
After creating the Infrastructure Configuration, save the ARN again, as we will need it for the Pipeline. Finally, we need to create a Distribution Configuration that will tell EC2IB which Regions to build the AMI, what to call it, and who to give access to use it. Despite the Console of EC2IB suggesting you can take advantage of the recently released (as of November 2021) ability to share AMIs with Organizations and Organizational Units (OUs), you cannot specify it within the Console nor the CLI. We will instead use the EC2 API to share the finalized AMI ID. This is not to be confused with the EC2IB Image resource itself - that can only be used within EC2IB as a Parent Image for other Recipes.
As before, we will start with a JSON CLI skeleton given the complex structure, and then issue the AWS CLI command, as shown below. Ensure you are replacing the value for $MY_REGION appropriately.
cat <<EOF >distro-config.json
{
"name": "Ubuntu2110MDEDistroConfig",
"description": "Creates an Ubuntu 21.10 Image with MDE in this Region",
"distributions": [
{
"region": "$MY_REGION",
"amiDistributionConfiguration": {
"name": "Ubuntu2110MDE-$MY_REGION-",
"description": "Ubuntu 21.10 with Microsoft Defender for Endpoint",
"amiTags": {
"CreatedBy": "$MY_ACCOUNT"
}
}
}
]
}
EOF
aws imagebuilder create-distribution-configuration --cli-input-json file://distro-config.json
This Distribution Configuration will only provide an Image in your current Region. It will automatically append the Region name as well as the date that the Image was built (using the EC2IB interpolated parameter) so that teams can ensure they use the latest (compared to other AMIs) Image. Like before, take down the ARN of this Distribution Configuration, we are finally ready to create our Pipeline.
The provided Schedule metadata will create a Cron job that runs on the second Tuesday of every month at 10:30 PM (22:30) UTC, with the start condition to fire only if the Cron job matches and if there are any updates found for the Components or upstream Packages. This should be communicated to teams who will consume this Image as they may have Regex rules or other automation to ensure they pull the latest monthly Image as well. We will create the Image by manually invoking the Pipeline, which may take up to 30 minutes to complete.
Navigate to the Image Pipelines section of the AWS EC2 Image Builder Console and select the Ubuntu2110MDEPipeline that was created. Underneath it, you should see the Output Images tab with a status message on the Image. This can take a long time depending on the infrastructure you are building on, how many Components are part of the Recipe, and the specific tests within them such as Tests and Validation. For our purposes, it should complete fast if all code examples were used as-is.
Once complete, we can now share our new "golden" Image with the rest of our AWS Organization with the EC2 API (modify-image-permissions) – this is an EC2 API that allows us to interact with the resource-based permissions of an AMI, traditionally this would be used to make an image fully public or share with specific accounts, but we can target our entire AWS Organization (or specific Organization Units) as required. This should not be confused with using AWS Resource Access Manager (RAM) to share the EC2IB Image object – that is a logical resource within EC2IB that can be used as a Parent Image for other Recipes. If we were to share the EC2IB Image (not the AMI) using RAM, all that would allow is access to the Image we baked as a source to another Recipe and not give the ability to launch a new instance.
Sharing with your AWS Organization
Once the status of the Image changes to Available, select the Images console from the left-hand navigation pane, select the hyperlink within the Version (should be 1.0.0/1), and copy the AMI ID under the Image column as shown below (FIG. 2).
Figure 2 - AMI ID for Images
Note: Also ensure you copy the ARN of the Image Builder Image.
We will now distribute the AMI to our entire AWS Organization within our Region. AMIs are regional resources. You will need to either modify the Distribution Configuration to build your AMI in other Regions or use the copy-image CLI command (or equivalent API/SDK method) to send the AMI to other Regions. Once there, a new AMI ID will be provided, and you'll need to create more RAM shares or use the EC2 APIs to share the AMI with other Accounts, OUs, or Organizations.
First, set an environment variable for your AWS Organizations using the describe-organization CLI command. The EC2 API to share AMIs requires the ARN which is why we are grabbing that value instead of the logical ID.
Set an environment variable for the freshly-baked AMI ID you copied in the previous steps. Ensure you replace the portion of the example code that says YOURAMIHERE with your actual ID number.
Share the AMI ID with your entire AWS Organization with the following commands which use the modify-image-attribute CLI command as part of the EC2 APIs.
At this point you can log into another AWS Account within your Organization to verify the AMI is shared success and in the region, you're in, it will have the same exact ID. To verify that it has been applied, you can use the following command. This will just verify that the modification to the launch permissions attributes is registered with the EC2 service.
Now that we have successfully built out our MDE-enabled Ubuntu 21.10 Image and shared it with our organization, we can go ahead and finish the registration, verify it reports to the MDE Console (which will prove future feasibility of post-provisioning setup), and get ready to clean-up our deployed resources. In the next entry of this blog post, readers will be provided with a version of the CloudFormation template that is used by the Panoptica Office of the CISO to bootstrap this setup and create automation to continue to build newer versions of this Image and distribute it to your entire organization. Additionally, we will provide the ability to perform post-launch configuration and register the MDE Agent and Tag it for your organization which will allow you to keep track of per-instance compliance with EDR/XDR coverage.
First, we will need to ensure the latest Activation script package is uploaded to our S3 Bucket. Navigate to the Microsoft 365 Defender Console and navigate to Settings in the left-hand navigation pane. Once there, select the Endpoints option and choose Onboarding with the new navigation pane for the sub-menu. Change the dropdown menu for the select operating system to start the onboarding process to Linux Server and select the Download onboarding package as shown below (FIG. 3).
Figure 3 - MDE Linux Onboarding Script
Upload the onboarding package to your S3 bucket that you also uploaded the EC2IB Component YAML file to with the following command.
When we create our EC2 Instance from our MDE-enabled AMI, we will be using User Data to provide the launch script and to ensure that provisioning happens at most once (by default) when the Instance launches. However, we will be downloading that package from S3 and will thus need permissions to do so, so we need to create another Instance Profile with associated IAM Policies and Roles.
Create a new IAM Policy, this will be attached to your Role along with the AWS-managed Policy that is needed for the Systems Manager to register your Instance. This specific Policy allows EC2 to download the MDE package from your S3 directory (/mdatp).
Now we will create and attach the rest of the Permissions required and associate them with a new IAM Instance Profile. As we have run similar commands, we won't deep dive into their purpose.
aws iam create-role \
--role-name MDEProvisionRole \
--description 'Provides minimum necessary permissions to EC2 to retrieve MDE Onboarding Packages and register with SSM' \
--path '/' \
--assume-role-policy-document file://trust-policy.json
sleep 1
aws iam attach-role-policy \
--role-name MDEProvisionRole \
--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
aws iam attach-role-policy \
--role-name MDEProvisionRole \
--policy-arn arn:aws:iam::$MY_ACCOUNT:policy/GetObjectForMDEPackage
aws iam create-instance-profile --instance-profile-name MDEProvisionRoleIP
sleep 1
aws iam add-role-to-instance-profile \
--instance-profile-name MDEProvisionRoleIP \
--role-name MDEProvisionRole
Now that our new Instance Profile is ready let's launch a new EC2 Instance with our new AMI. Firstly, we must set what our User Data will be. User Data, again, will provide us a way to inject the commands we want our EC2 Instance to run as it is being launched - this may be a preferred way for developers and engineers to build their Kubernetes and Container hosts as they can tightly couple their post-provisioning with their infrastructure code and version control it from there. The cloud-init service (which provides the engine to run the User Data) can be modified to run it upon every launch if you desire as well. Luckily, the AWS CLI will handle Base64 encoding and formatting of the User Data so we do need to worry about it, we can just load from a Text File, provided that the final size of the User Data will not exceed 16 KB.
Paste the following text into a file named userdata.txt Ensure that you ONLY replace the value of $MY_BUCKET with your S3 Bucket, and not anything else, as it is not needed for the script.
#!/bin/bash
apt install --only-upgrade mdatp -y
aws s3 cp s3://$MY_BUCKET/mdatp/WindowsDefenderATPOnboardingPackage.zip .
unzip WindowsDefenderATPOnboardingPackage.zip
python3 MicrosoftDefenderATPOnboardingLinuxServer.py
mdatp threat policy set --type potentially_unwanted_application --action audit
export INSTANCE_ID=$(curl http://169.254.169.254/latest/meta-data/instance-id)
mdatp edr tag set --name GROUP --value $INSTANCE_ID
Important Note: You will need to modify the command to include a Key Pair if you do not use Session Manager to access your Instances. It has been observed that Session Manager may not even work on Ubuntu 21.10LTS despite successful installation during the EC2IB Pipeline build.
It may take up to 15 minutes for the Instance to register with the MDE Device Inventory Console, but there may not be any vulnerability data available right away. In the below screenshot (FIG. 4), an example of this exact same build is shown which has drastically lower amounts of vulnerabilities (though some still do exist) versus a standard Ubuntu 18.04LTS or 20.04LTS Image. This is important to note for DevOps or Cloud Infrastructure Security teams who are overseeing OS builds, that despite using the most up-to-date AMIs that have minimal components, there will still be baked-in vulnerabilities. You should prioritize exploitable vulnerabilities or vulnerabilities that are targeted by threat actors within your sphere of influence - whether they are cybercriminals, State or State-sponsored, or opportunistic attackers who have favored vulnerabilities to target.
Figure 4 - Ubuntu 21.10 Image in MDE Device Inventory
Conclusion & Cleaning Up
Before closing, we will clean up all the resources and services we had deployed, if you want to keep what you built feel free to skip these next few steps. Unfortunately, you cannot Offboard the instance via automation, as it is an unsupported OS version, you will need to wait for the instance to deregister from Device Inventory or locally install and run the offboarding script provided from your Microsoft 365 Defender console. However, to remove all other components, run the following commands.
aws ec2 terminate-instances --instance-ids $MDE_INSTANCE_ID
aws imagebuilder delete-image --image-build-version-arn arn:aws:imagebuilder:$MY_REGION:$MY_ACCOUNT:image/minimalubuntu2110withmde/1.0.0/1
aws imagebuilder delete-image-pipeline --image-pipeline-arn arn:aws:imagebuilder:$MY_REGION:$MY_ACCOUNT:image-pipeline/ubuntu2110mdepipeline
aws imagebuilder delete-image-recipe --image-recipe-arn arn:aws:imagebuilder:$MY_REGION:$MY_ACCOUNT:image-recipe/minimalubuntu2110withmde/1.0.0
aws imagebuilder delete-component --component-build-version-arn arn:aws:imagebuilder:$MY_REGION:$MY_ACCOUNT:component/installmdeubuntu/1.0.0/1
aws imagebuilder delete-distribution-configuration --distribution-configuration-arn arn:aws:imagebuilder:$MY_REGION:$MY_ACCOUNT:distribution-configuration/ubuntu2110mdedistroconfig
aws imagebuilder delete-infrastructure-configuration --infrastructure-configuration-arn arn:aws:imagebuilder:$MY_REGION:$MY_ACCOUNT:infrastructure-configuration/mdeinfraconfig
aws iam remove-role-from-instance-profile --instance-profile-name EC2IBInstanceProfile --role-name EC2IBRole
aws iam delete-instance-profile --instance-profile-name EC2IBInstanceProfile
aws iam detach-role-policy --role-name EC2IBRole --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
aws iam detach-role-policy --role-name EC2IBRole --policy-arn arn:aws:iam::aws:policy/EC2InstanceProfileForImageBuilder
aws iam delete-role --role-name EC2IBRole
aws iam remove-role-from-instance-profile --instance-profile-name MDEProvisionRoleIP --role-name MDEProvisionRole
aws iam delete-instance-profile --instance-profile-name MDEProvisionRoleIP
aws iam detach-role-policy --role-name MDEProvisionRole --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
aws iam detach-role-policy --role-name MDEProvisionRole --policy-arn arn:aws:iam::$MY_ACCOUNT:policy/GetObjectForMDEPackage
aws iam delete-role --role-name MDEProvisionRole
aws iam delete-policy --policy-arn arn:aws:iam::$MY_ACCOUNT:policy/GetObjectForMDEPackage
aws ec2 deregister-image --image-id $MDE_AMI_ID --no-dry-run
In this blog, we demonstrated how to use AWS EC2 Image Builder to create a brand new AMI that had the required dependencies for running Microsoft Defender for Endpoint and the AWS Systems Manager Agent. We dove into the various parts of the EC2 Image Builder and built them using the AWS CLI as well as set up the required AWS IAM Policies, Roles, and Instance Profiles to grant permissions to the various services. We were able to share our new AMI with our entire AWS Organization, which is the fastest way to distribute an AMI to be used. Finally, we used our fresh baked AMI to launch a new EC2 Instance and finalized the configuration of Microsoft Defender for Endpoint on our Ubuntu 21.10 Minimal EC2 Instance, and did a light analysis of the (relative) lack of vulnerabilities.
Using EC2 Image Builder and User Data within your Infrastructure-as-Code or infrastructure-built scripts is a great way to get started with a secure baseline upon which you can build your applications, run your containers or Kubernetes clusters. By choosing a "Minimal" image with the latest flavor of your preferred operating system, you can get ahead of the vulnerability and patch management curve by starting with the least number of vulnerabilities and thus drastically reducing the attack surface for internet-borne attacks. In a production environment, you should strongly consider additional hardening techniques such as using CIS or DISA STIG guidelines, further removing unnecessary components, and exploring mobility onto another OS such as Amazon Linux 2 or Amazon Linux 2022 to further reduce vulnerability "debt." This is also not a substitute for other strong cloud security measures such as implementing network and identity security products, performing threat-centric evaluations such as Breach & Attack Simulations, or looking into a platform like Panoptica to help you identify legitimate attack paths and security misconfigurations from your codebase to your workload runtimes.
SIGN UP FREE
