There were a number of questions asked related to our recent TechTalk: Leveraging the R80.10 API to Automate and Streamline Security Operations
An edited list of questions and answers (with duplicates removed) are provided below.
The API server is on management only, similar to how it worked in previous versions.
Not currently.
There are features in the API today you can leverage to make an intelligent decision about where new rules can be placed. However, the automation will have to make the decision. To aid in this process, we are developing a Rule Assistant capability. This is currently in early availability. If you would like to participate, contact your Check Point SE or send me (Dameon Welch Abernathy) a private message.
As long as it can be configured to use our REST API, yes.
There a couple in the Developers (Code Hub) space:
For a single gateway, yes. For a cluster, it's roadmap. See: https://sc1.checkpoint.com/documents/latest/APIs/index.html#gui-cli/set-simple-gateway~v1.1
You can prevent certain logins from using the API, but you can not prevent API credentials from also using SmartConsole.
Yes, including cprid_util. See these threads:
It's a separate API, but R80.10 includes it.
Refer to the following docs: Configuring Identity Sources
It's not specific to R80.10, but yes. We even have a space for it on CheckMates: SandBlast API
Yes:
While SmartDashboard permits authentication via certificate, this cannot currently be done via the API.
All administrator users are assigned a permissions profile. API access will be restricted by these permission profiles. Refer to the following documentation: Managing Administrator Accounts
Currently there is no way to apply access control to a specific object (either you have the ability to edit them or you don't). You can, however, apply permissions to policy layers.
See:How-to use Postman with R80 Security Management API
Yes
No
Domains can be created via the API, but virtual systems require use of the CLI (vsx_provisioning_tool).
If changes are required to the API, this will be documented and a new version will be made. For example, there were minor changes from R80 to R80.10, thus the version went from version 1.0 to 1.1.
Device provisioning features are not in the scope of the current APIs. This is on the roadmap.
Not at the moment, though there is nothing inherent with the APIs that would preclude using these tools.
Yes, you can determine the position the rule is added. Refer to API docs: Check Point - Management API reference
Not at this time.
This is something available in Early Availability form from SmartConsole:
Yes, here's a sample.
Before you can delete any object, you have to delete references to it (e.g. in groups). Use the where-used option in the API to find the places you will need to remove the object before you can finally remove the object.
Yes, this can be done as part of the login action to the API.
As is, no.
The Central Deployment Tool (CDT) is meant to maintain the OS, software, and patches on security gateways. The R80.10 API is focused on security policy mangement.
They are included here: CheckMates_Aug15_Demos.zip
Database revisions work differently in R80/R80.10. Read more here: How to revert a Policy or discard changes?
Generally it's more efficient to make a bunch of changes and do a single publish operation. If the number of changes is large (say, several thousand), it may be better to break it up into smaller chunks and do a commit at each one.
There are some functions that still rely on CPMI. Specifically things relating to Security Gateway objects or any features (e.g. HTTPS Inspection) that need to be configured with SmartDashboard.
You cannot fetch AD users through the R80.x API but you can create Access Roles and rules that use them.
Threat Prevention in general has an API: Threat Prevention API 1.0 Reference Guide. However, it does not include managing IoCs. In R80.10, this can only be currently done through SmarConsole.
This is not currently available.
