Fetch a List of Controls

GET/v1.3/controls

Input ParametersInput Parameters

Parameter

Mandatory/Optional

Data Type

Description

filter

Optional

string

Filter the controls list by providing a query using Qualys syntax.

Refer to the “How to Search” topic in the online help for assistance with creating your query

pageNumber

Optional

integer

The page to be returned.

The default is 1.

pageSize

Optional

integer

The number of records per page to be included in the response.

The default value is 50.

sort

Optional

string

Sort the results using a Qualys token. For example created:desc.

Refer to the “Sortable tokens” topic in the online help for more information.

Sample: Fetch a List of ControlsSample: Fetch a List of Controls

API request

    curl -X GET 
"<qualys_base_url>/csapi/v1.3/controls?pageNumber=1&pageSize=50&sort=created%3Adesc" --header "Authorization: Bearer <token>"
    

Response

    {
    "data": [
        {
            "id": 18990,
            "statement": "Status of the host devices and their exposure",
            "criticality": "SERIOUS",
            "comments": "STMT: Status of the host devices and their exposure\n\nRAT: Host devices can be directly exposed to containers at runtime. Do not directly expose host devices to containers, especially to containers that are not trusted. The --device option exposes host devices to containers and as a result of this, containers can directly access these devices. The  container would not need to run in privileged mode to access and manipulate them, as by default, the container is granted this type of access. Additionally, it would possible for containers to remove block devices from the host. You therefore should not expose host devices to containers directly. If for some reason you wish to expose the host device to a container you should consider which sharing permissions you wish to use on a case by case base as appropriate to your organization.\n\n\n----\nOld mappings before granular NIST was added: New control\n\nGranular mapping:\nAC-1, ACCESS CONTROL POLICY AND PROCEDURES\n\nDelete Old Mapping:N/A\nGranular Mapping: Yes\nGranular Mapping Review: No",
            "deprecated": "Control is not deprecated",
            "category": "OS Security Settings",
            "subCategory": "System Settings (OSI layers 6-7)",
            "technologies": [
                {
                    "id": 181,
                    "name": "Docker CE/EE",
                    "rational": "Host devices can be directly exposed to containers at runtime. Do not directly expose host devices to containers, especially to containers that are not trusted. The --device option exposes host devices to containers and as a result of this, containers can directly access these devices. The  container would not need to run in privileged mode to access and manipulate them, as by default, the container is granted this type of access. Additionally, it would possible for containers to remove block devices from the host. You therefore should not expose host devices to containers directly. If for some reason you wish to expose the host device to a container you should consider which sharing permissions you wish to use on a case by case base as appropriate to your organization.",
                    "remediation": "You should not directly expose host devices to containers. If you do need to expose host devices to containers, you should use granular permissions as appropriate to your organization:\nFor example, do not start a container using the command below:\ndocker run --interactive --tty --device=/dev/tty0:/dev/tty0:rwm --device=/dev/temp_sda:/dev/temp_sda:rwm centos bash\nYou should only share the host device using appropriate permissions:\ndocker run --interactive --tty --device=/dev/tty0:/dev/tty0:rw --device=/dev/temp_sda:/dev/temp_sda:r centos bash"
                },
                {
                    "id": 283,
                    "name": "Docker Containers/Images",
                    "rational": "Host devices can be directly exposed to containers at runtime. Do not directly expose host devices to containers, especially to containers that are not trusted. The --device option exposes host devices to containers and as a result of this, containers can directly access these devices. The  container would not need to run in privileged mode to access and manipulate them, as by default, the container is granted this type of access. Additionally, it would possible for containers to remove block devices from the host. You therefore should not expose host devices to containers directly. If for some reason you wish to expose the host device to a container you should consider which sharing permissions you wish to use on a case by case base as appropriate to your organization.",
                    "remediation": "You should not directly expose host devices to containers. If you do need to expose host devices to containers, you should use granular permissions as appropriate to your organization:\nFor example, do not start a container using the command below:\ndocker run --interactive --tty --device=/dev/tty0:/dev/tty0:rwm --device=/dev/temp_sda:/dev/temp_sda:rwm centos bash\nYou should only share the host device using appropriate permissions:\ndocker run --interactive --tty --device=/dev/tty0:/dev/tty0:rw --device=/dev/temp_sda:/dev/temp_sda:r centos bash"
                }
            ]
        },
        {
            "id": 10808,
            "statement": "Status of the 'cap-drop' flag settings on Docker containers on the host system",
            "criticality": "CRITICAL",
            "comments": "STMT: Status of the 'cap-drop' flag settings on Docker containers on the host system\n\nRAT: Linux Capabilities allows dividing privileges associated with superuser into distinct group of smaller units, known as capabilities.  By default, Docker containers are started with a restricted set of capabilities where each one can be independently enabled and disabled.  This enables the processes running inside a container to perform almost all the specific areas where root privileges are usually needed without having to have them run as root.  Unrestricted Linux capabilities could allow unauthorized access to containers which could potentially lead to attacks such as privilege escalation exploits.  Linux Capabilities on Docker containers should be restricted as appropriate to the needs of the business to have only those that are required for the containers to perform their function.\n\nCIS_Docker_1.11.0_Benchmark_v1.0.0: 5.3 Restrict Linux Kernel Capabilities within containers\nCIS_Docker_1.12.0_Benchmark_v1.0.0: 5.3 Restrict Linux Kernel Capabilities within containers",
            "deprecated": "Control is not deprecated",
            "category": "Access Control Requirements",
            "subCategory": "Authorization (Single-user ACL/role)",
            "technologies": [
                {
                    "id": 112,
                    "name": "Docker 1.x",
                    "rational": "Linux Capabilities allows dividing privileges associated with superuser into distinct group of smaller units, known as capabilities.  By default, Docker containers are started with a restricted set of capabilities where each one can be independently enabled and disabled.  This enables the processes running inside a container to perform almost all the specific areas where root privileges are usually needed without having to have them run as root.  Unrestricted Linux capabilities could allow unauthorized access to containers which could potentially lead to attacks such as privilege escalation exploits.  Linux Capabilities on Docker containers should be restricted as appropriate to the needs of the business to have only those that are required for the containers to perform their function.",
                    "remediation": "Run the following command to verify that the added and dropped Linux Kernel Capabilities are in line with the ones needed for container process for each container instance.\n# docker ps --quiet | xargs docker inspect --format '}: CapAdd=} CapDrop=}'\n\nRun the following command to add needed capabilities:\n# docker run --cap-add={\"Capability 1\",\"Capability 2\"} <run-arguments> <container-image-name-or-ID> <command>\n\nFor example,\n# docker run --interactive --tty --cap-add={\"NET_ADMIN\",\"SYS_ADMIN\"} centos:latest /bin/bash\n\nTo drop unneeded capabilities, run the following command:\n# docker run --cap-drop={\"Capability 1\",\"Capability 2\"} <run-arguments> <container-image-name-or-ID> <command>\n\nFor example, \ndocker run --interactive --tty --cap-drop={\"SETUID\",\"SETGID\"} centos:latest /bin/bash\n\nAlternatively, drop all capabilities and add only add only those that are the needed:\n# docker run --cap-drop=all --cap-add={\"Capability 1\",\"Capability 2\"} <run-arguments> <container-image-name-or-ID> <command>\n\nFor example, \ndocker run --interactive --tty --cap-drop=all --cap-add={\"NET_ADMIN\",\"SYS_ADMIN\"} centos:latest /bin/bash"
                },
                {
                    "id": 181,
                    "name": "Docker CE/EE",
                    "rational": "Linux Capabilities allows dividing privileges associated with superuser into distinct group of smaller units, known as capabilities.  By default, Docker containers are started with a restricted set of capabilities where each one can be independently enabled and disabled.  This enables the processes running inside a container to perform almost all the specific areas where root privileges are usually needed without having to have them run as root.  Unrestricted Linux capabilities could allow unauthorized access to containers which could potentially lead to attacks such as privilege escalation exploits.  Linux Capabilities on Docker containers should be restricted as appropriate to the needs of the business to have only those that are required for the containers to perform their function.",
                    "remediation": "Run the following command to verify that the added and dropped Linux Kernel Capabilities are in line with the ones needed for container process for each container instance.\n# docker ps --quiet | xargs docker inspect --format '}: CapAdd=} CapDrop=}'\n\nRun the following command to add needed capabilities:\n# docker run --cap-add={\"Capability 1\",\"Capability 2\"} <run-arguments> <container-image-name-or-ID> <command>\n\nFor example,\n# docker run --interactive --tty --cap-add={\"NET_ADMIN\",\"SYS_ADMIN\"} centos:latest /bin/bash\n\nTo drop unneeded capabilities, run the following command:\n# docker run --cap-drop={\"Capability 1\",\"Capability 2\"} <run-arguments> <container-image-name-or-ID> <command>\n\nFor example, \ndocker run --interactive --tty --cap-drop={\"SETUID\",\"SETGID\"} centos:latest /bin/bash\n\nAlternatively, drop all capabilities and add only add only those that are the needed:\n# docker run --cap-drop=all --cap-add={\"Capability 1\",\"Capability 2\"} <run-arguments> <container-image-name-or-ID> <command>\n\nFor example, \ndocker run --interactive --tty --cap-drop=all --cap-add={\"NET_ADMIN\",\"SYS_ADMIN\"} centos:latest /bin/bash"
                },
                {
                    "id": 283,
                    "name": "Docker Containers/Images",
                    "rational": "Linux Capabilities allows dividing privileges associated with superuser into distinct group of smaller units, known as capabilities.  By default, Docker containers are started with a restricted set of capabilities where each one can be independently enabled and disabled.  This enables the processes running inside a container to perform almost all the specific areas where root privileges are usually needed without having to have them run as root.  Unrestricted Linux capabilities could allow unauthorized access to containers which could potentially lead to attacks such as privilege escalation exploits.  Linux Capabilities on Docker containers should be restricted as appropriate to the needs of the business to have only those that are required for the containers to perform their function.",
                    "remediation": "Run the following command to verify that the added and dropped Linux Kernel Capabilities are in line with the ones needed for container process for each container instance.\n# docker ps --quiet | xargs docker inspect --format '}: CapAdd=} CapDrop=}'\n\nRun the following command to add needed capabilities:\n# docker run --cap-add={\"Capability 1\",\"Capability 2\"} <run-arguments> <container-image-name-or-ID> <command>\n\nFor example,\n# docker run --interactive --tty --cap-add={\"NET_ADMIN\",\"SYS_ADMIN\"} centos:latest /bin/bash\n\nTo drop unneeded capabilities, run the following command:\n# docker run --cap-drop={\"Capability 1\",\"Capability 2\"} <run-arguments> <container-image-name-or-ID> <command>\n\nFor example, \ndocker run --interactive --tty --cap-drop={\"SETUID\",\"SETGID\"} centos:latest /bin/bash\n\nAlternatively, drop all capabilities and add only add only those that are the needed:\n# docker run --cap-drop=all --cap-add={\"Capability 1\",\"Capability 2\"} <run-arguments> <container-image-name-or-ID> <command>\n\nFor example, \ndocker run --interactive --tty --cap-drop=all --cap-add={\"NET_ADMIN\",\"SYS_ADMIN\"} centos:latest /bin/bash"
                }
            ]
        }
    ],
    "count": "26"
}