loader image
X
cloudnosys logo
Custom Signatures

Custom Signatures represent a premium feature of Cloudnosys, specifically designed for users who wish to craft their own security rules. This feature is ideal for those who require a tailored approach to security.

Why create Custom Signatures?

Custom Signatures empower you to create bespoke security rules that align perfectly with your unique requirements. Whether it’s addressing specific vulnerabilities or enforcing particular compliance standards, this feature provides the flexibility and precision needed to enhance your security posture.


Creating a Custom Signature #

Let’s suppose you want to check whether MFA (Multi-factor Authentication) is enabled for all IAM users that have a passwords.

Navigate to the Custom Signatures tab on the Risks page and click on the “Add New Signature” button.


Page Overview #

This page is divided into 2 sections:


  1. Signature Meta: Here you need to put the signature’s metadata, such as signature description (AKA Title), Page Detail, and so on.
  2. Code Editor: This is a JavaScript code editor. In the example shown above there is a function in which we have two parameters:
    • API Caller: Sends the network & API calls to the Cloud Provider e.g AWS, and
    • Resource: Checks each resource against response.


Code Editor #

The bottom section of the Code Editor has two tabs:

i. Console: It shows the status of the signature and whether it ran successfully or failed.


ii. Resource Checker: Lists all the resources with their Service, Region, VPC, and Status. 


Signature Meta #

The Signature ID is auto-generated. 

Description #

Here you define your main objective of creating a signature such as “Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a password”

Page Detail #

A detailed demonstration of your objective. In our example, it could be:

“Having MFA-protected IAM users is the best way to protect your AWS resources and services against attackers. An MFA device signature adds an extra layer of protection on top of your existing IAM user credentials (username and password), making your AWS account virtually impossible to penetrate without the MFA-generated passcode.”

Cloud Provider #

Select the cloud provider associated with your custom security check. In our example, we will select AWS:

Service #

Select the service this signature is associated with. Since we are creating a signature for IAM, we will select “IAM”.

Risk Level #

The severity of the risk that will arise if this signature fails on a resource. We get risk notifications according to different severities:

  • High: The issue must be addressed as a priority.
  • Medium: The issue must be addressed but not urgently.
  • Low: The issue does not require action on its own.

In our example, since IAM password protection involves high risk we will select “High”.

Category #

This is related to Cloud Services (IAM, EC2, S3) of a Signature.

Function #

This is related to the action or what defines the Signature description. In our example, we will select “Access Control”.

Group #

This is how we would like to pair various signatures together. For our example, we will select “IAM”.

Pass Message #

This is the message that will be displayed for resources that pass this custom security check. For example, we can state it as: “Multi-factor authentication (MFA) is enabled for all IAM users that have a password.”

Fail Message #

This is the message that will be displayed for resources that do NOT pass this custom security check. For example, we can state it as: “Multi-factor authentication (MFA) is enabled for all IAM users that have a password.”

Remediation Steps #

When the signature shows errors/fails to run the command in the output, write steps that should be followed to fix that bug.

We can write the following steps for our example:

Perform the following to enable MFA:

  1. Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/
  2. In the navigation pane, choose Users.
  3. In the User Name list, choose the name of the intended MFA user.
  4. Choose the Security Credentials tab, and then choose Manage MFA Device.
  5. In the Manage MFA Device wizard, choose A virtual MFA device, and then choose Next Step.
  6. Open your virtual MFA application.
    • For a list of apps that you can use for hosting virtual MFA devices, see Virtual MFA Applications.
    • If the virtual MFA application supports multiple accounts (multiple virtual MFA devices), choose the option to create a new account (a new virtual MFA device).
  7. Determine whether the MFA app supports QR codes, and then do one of the following:
    • Use the app to scan the QR code. For example, you might choose the camera icon or choose an option similar to Scan code, and then use the device’s camera to scan the code.
    • In the Manage MFA Device wizard, choose Show secret key for manual configuration, and then type the secret configuration key into your MFA application.
    • When you are finished, the virtual MFA device starts generating one-time passwords.
  8. In the Manage MFA Device wizard, in the Authentication Code 1 box, type the one-time password that currently appears in the virtual MFA device.
  9. Wait up to 30 seconds for the device to generate a new one-time password.
  10. Type the second one-time password into the Authentication Code 2 box.
  11. Choose Active Virtual MFA.


Using the Code Editor #

Now move to the JavaScript code editor, which is on the right side of the screen.

It contains a try & catch block. In the try block, we are using a function named apiCaller for getting the response. This function is used to make API calls to the Cloud Provider, for e.g: AWS.

The resource parameter contains all the data related to a resource.

Execute the following steps:

1. Define the service “IAM” inside the apiCaller block


2. Service params: Add the API version. AWS services have API version numbers to keep track of API compatibility.


3. Specify the region in which you want to test the service. Here, the “us-east-1” is a global region but if you have a service for which you want to test the signature in all regions then use region:[resource.region].


4. An Endpoint object represents the endpoint URL for service requests. Add Endpoint endpoint:listMFADevices  from AWS documentation.


5. Add the name of the user in params whose MFA devices you want to list params: {UserName: “JamesMichael”}.

If you do not know usernames then you can list all users like this {UserName: resource.name} 


6. Now, if you want to see the API response of your signature in the console, then add console.log(apiResponse); after the apiCaller block. It will list all of your MFADevices in the “us-east-1” Region and it’ll look like the following.


7. In return, we define the signature status and the status message:

  • statusSig: Return a boolean value. Either “true” or “false”, depending upon the signature status
  • statusMessage: (Optional) Define the status message of the signature for pass & fail.


8. Add condition if apiResponse length is 0 then that means multi-factor authentication is not enabled. Otherwise, if it’s enabled, then your code editor will look like this:

module.exports = async function(apiCaller, resource){
  try {
    const apiResponse = await apiCaller({
      service: "IAM",
      serviceParams: { apiVersion: "2010-05-08", region:[resource.region] },
      endpoint: "listMFADevices",
      params: {UserName: resource.name }
    });
   // console.log(apiResponse);
    // checking mfa is enabled or not
         if (
          apiResponse &&
          apiResponse[0] &&
          apiResponse[0][0].apiResponse.length === 0
        ) 
         {
            return { statusSig: true, statusMessage: "MFA is enabled" };
         } else {
          return { statusSig: false, statusMessage: "MFA is not enabled" };
        }
  } catch (err) {
    return { statusSig: false, statusMessage: "" };
  }
};


9. Now click on the “Test” button. You will see response like this:

Console tab:

Resources Checked tab: It will list all the resources of your signature with their status & other information.


Now click on ”Save” and your signature is ready.


Limitations #

  • The total execution time of running a Custom Signature is 60 seconds.
  • All code executions are handled via a sandbox environment.
  • The eval function is not allowed.
  • Accessing any file system is restricted.

Was this page helpful?