To use app-id effectively in security policies which three best practices should be followed

For some areas on campus, the firewalls contain rules which were migrated from a non-Palo Alto firewall. The technique used during the migration implemented a naming scheme seen below (these rule names are editable by the fw-admin):

"Vlan-####-Rule-##"

During the firewall migration the engineers implemented a naming schema for tags to provide clarity. The naming scheme begins with the traffic direction, followed by the departmental code, then the VLAN number, then the name of the physical firewall where the rule resides. Examples are:

"IN-UNITSHORTCODE-VLAN-FIREWALLNAME"

"OUT-UNITSHORTCODE-VLAN-FIREWALLNAME"

By default, all manually created rules are created with the type Universal. The rule "type" can change from Universal to inter/intra-zone to limit unwanted access. 

• Intrazone rule type manages the traffic within a zone.
• Interzone rule type manages the traffic between zones.
• Universal rule type includes both Intra and inter-zone traffic.

When applying Security Zones, it is best practice from Palo Alto to avoid "Any" in the source or destination zone fields. This opens the possibility for the "any-any" rule to unintentionally allow sessions that are not accounted for or unintended. Rather, use specific zones for the desired source or destination.

When the firewall processes a packet it takes the packet and attempts to match it to a rule to allow the packet to flow through the firewall.

• The first check happens outside the Network security policies, under the DoS (Denial of Service) and Zone protection policies, to protect against: network floods, Denial of Service attacks and host scanning.
• By nature, these attacks act on networks before the delivery stage of the cyber-attack lifecycle.
• The firewall then checks any packets that passes these checks against the security policies first matching the destination address.
• The security policies are processed from the top down and then read from left to right to find a rule match.
• Caution: This top-down logic allows for rules to be "shadowed", which occurs when a more general rule is placed above a rule with a more specific source, destination or service object.
• Once it has reached a match for the request, the firewall stops and acts on the packet according to the action specified by the rule and logs the event based on the logging profile setting.
• During the request the application-id, as recognized on the network, can change when more information is communicated between hosts during TCP life cycle; which can cause the connection to shift to a different rule in the security policy.

The concept of the Application ID feature is the Next Generation feature which the Palo Alto firewalls provide, to verify access requests match the official use-case.

• Palo Alto has generated Application Identifications based on network hash information, matching traffic specific to the application used.
• Application IDs are stored online in their website here.
• Review this KB article on Application-ID specifics for more information.

Palo Alto by default has columns hidden, these can be shown by hovering over a column header to display sub-menus.

Rule Usage

With PAN OS version 8.1 the Rule Usage hit-counters were provided for each rule. As seen in the above image the rule usage is broken down into Hit Count, Last Hit and First Hit.

This translates into:

• Hit Count: Number of times the rule has been hit since the last hit-counter reset
  
  
• Last Hit: The time-stamp for the latest packet to match the rule
• First Hit: The time-stamp for the first time the rule was hit

To help secure your AWS resources, follow these best practices for AWS Identity and Access Management (IAM) .

Require human users to use federation with an identity provider to access AWS using temporary credentials

Human users, also known as human identities, are the people, administrators, developers, operators, and consumers of your applications. They must have an identity to access your AWS environments and applications. Human users that are members of your organization are also known as workforce identities. Human users can also be external users with whom you collaborate, and who interact with your AWS resources. They can do this via a web browser, client application, mobile app, or interactive command-line tools.

Require your human users to use temporary credentials when accessing AWS. You can use an identity provider for your human users to provide federated access to AWS accounts by assuming roles, which provide temporary credentials. For centralized access management, we recommend that you use AWS IAM Identity Center (successor to AWS Single Sign-On) (IAM Identity Center) to manage access to your accounts and permissions within those accounts. You can manage your user identities with IAM Identity Center, or manage access permissions for user identities in IAM Identity Center from an external identity provider. For more information, see What is AWS IAM Identity Center (successor to AWS Single Sign-On) in the AWS IAM Identity Center (successor to AWS Single Sign-On) User Guide.

For more information about roles, see Roles terms and concepts.

Require workloads to use temporary credentials with IAM roles to access AWS

A workload is a collection of resources and code that delivers business value, such as an application or backend process. Your workload can have applications, operational tools, and components that require an identity to make requests to AWS services, such as requests to read data. These identities include machines running in your AWS environments, such as Amazon EC2 instances or AWS Lambda functions.

You can also manage machine identities for external parties who need access. To give access to machine identities, you can use IAM roles. IAM roles have specific permissions and provide a way to access AWS by relying on temporary security credentials with a role session. Additionally, you might have machines outside of AWS that need access to your AWS environments. For machines that run outside of AWS you can use AWS Identity and Access Management Roles Anywhere. For more information about roles, see IAM roles. For details about how to use roles to delegate access across AWS accounts, see IAM tutorial: Delegate access across AWS accounts using IAM roles.

Require multi-factor authentication (MFA)

We recommend using IAM roles for human users and workloads that access your AWS resources so that they use temporary credentials. However, for scenarios in which you need IAM or root users in your account, require MFA for additional security. With MFA, users have a device that generates a response to an authentication challenge. Each user's credentials and device-generated response are required to complete the sign-in process. For more information, see Using multi-factor authentication (MFA) in AWS.

If you use IAM Identity Center for centralized access management for human users, you can use the IAM Identity Center MFA capabilities when your identity source is configured with the IAM Identity Center identity store, AWS Managed Microsoft AD, or AD Connector. For more information about MFA in IAM Identity Center see Multi-factor authentication in the AWS IAM Identity Center (successor to AWS Single Sign-On) User Guide.

Rotate access keys regularly for use cases that require long-term credentials

Where possible, we recommend relying on temporary credentials instead of creating long-term credentials such as access keys. However, for scenarios in which you need IAM users with programmatic access and long-term credentials, we recommend that you rotate access keys. Regularly rotating long-term credentials helps you familiarize yourself with the process. This is useful in case you are ever in a situation where you must rotate credentials, such as when an employee leaves your company. We recommend that you use IAM access last used information to rotate and remove access keys safely. For more information, see Rotating access keys.

There are specific use cases that require long-term credentials with IAM users in AWS. Some of the use cases include the following:

• Programmatic use cases that cannot use IAM roles – You might run code from a location that needs to access AWS. In some situations, you can't use IAM roles to provide temporary credentials, such as for WordPress plugins. In these situations, use IAM user long-term access keys for that code to authenticate to AWS.

• Third-party AWS clients – If you are using tools that don’t support access with IAM Identity Center, such as third-party AWS clients or vendors that are not hosted on AWS, use IAM user long-term access keys.

• AWS CodeCommit access – If you are using CodeCommit to store your code, you can use an IAM user with either SSH keys or service-specific credentials for CodeCommit to authenticate to your repositories. We recommend that you do this in addition to using a user in IAM Identity Center for normal authentication. Users in IAM Identity Center are the people in your workforce who need access to your AWS accounts or to your cloud applications. To give users access to your CodeCommit repositories without configuring IAM users, you can configure the git-remote-codecommit utility. For more information about IAM and CodeCommit, see Using IAM with CodeCommit: Git credentials, SSH keys, and AWS access keys. For more information about configuring the git-remote-codecommit utility, see Connecting to AWS CodeCommit repositories with rotating credentials in the AWS CodeCommit User Guide.

• Amazon Keyspaces (for Apache Cassandra) access – In a situation where you are unable to use users in IAM Identity Center, such as for testing purposes for Cassandra compatibility, you can use an IAM user with service-specific credentials to authenticate with Amazon Keyspaces. Users in IAM Identity Center are the people in your workforce who need access to your AWS accounts or to your cloud applications. You can also connect to Amazon Keyspaces using temporary credentials. For more information, see Using temporary credentials to connect to Amazon Keyspaces using an IAM role and the SigV4 plugin in the Amazon Keyspaces (for Apache Cassandra) Developer Guide.

Safeguard your root user credentials and don't use them for everyday tasks

When you create an AWS account you establish a root user name and password to sign in to the AWS Management Console. Safeguard your root user credentials the same way you would protect other sensitive personal information. You can do this by configuring MFA for your root user credentials. We don't recommend generating access keys for your root user, because they allow full access to all your resources for all AWS services, including your billing information. Don’t use your root user for everyday tasks. Use the root user to complete the tasks that only the root user can perform. For the complete list of these tasks, see Tasks that require root user credentials in the AWS General Reference. For more information, see Best practices to protect your account's root user in the AWS Account Management User Guide.

Apply least-privilege permissions

When you set permissions with IAM policies, grant only the permissions required to perform a task. You do this by defining the actions that can be taken on specific resources under specific conditions, also known as least-privilege permissions. You might start with broad permissions while you explore the permissions that are required for your workload or use case. As your use case matures, you can work to reduce the permissions that you grant to work toward least privilege. For more information about using IAM to apply permissions, see Policies and permissions in IAM.

Get started with AWS managed policies and move toward least-privilege permissions

To get started granting permissions to your users and workloads, use the AWS managed policies that grant permissions for many common use cases. They are available in your AWS account. Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they are available for use by all AWS customers. As a result, we recommend that you reduce permissions further by defining customer managed policies that are specific to your use cases. For more information, see AWS managed policies. For more information about AWS managed policies that are designed for specific job functions, see AWS managed policies for job functions.

Use IAM Access Analyzer to generate least-privilege policies based on access activity

To grant only the permissions required to perform a task, you can generate policies based on your access activity that is logged in AWS CloudTrail. IAM Access Analyzer analyzes the services and actions that your IAM roles use, and then generates a fine-grained policy that you can use. After you test each generated policy, you can deploy the policy to your production environment. This ensures that you grant only the required permissions to your workloads. For more information about policy generation, see IAM Access Analyzer policy generation.

You might have IAM users, roles, permissions, policies, or credentials that you no longer need in your AWS account. IAM provides last accessed information to help you identify the users, roles, permissions, policies, and credentials that you no longer need so that you can remove them. This helps you reduce the number of users, roles, permissions, policies, and credentials that you have to monitor. You can also use this information to refine your IAM policies to better adhere to least-privilege permissions. For more information, see Refining permissions in AWS using last accessed information.

Use conditions in IAM policies to further restrict access

You can specify conditions under which a policy statement is in effect. That way, you can grant access to actions and resources, but only if the access request meets specific conditions. For example, you can write a policy condition to specify that all requests must be sent using SSL. You can also use conditions to grant access to service actions, but only if they are used through a specific AWS service, such as AWS CloudFormation. For more information, see IAM JSON policy elements: Condition.

Verify public and cross-account access to resources with IAM Access Analyzer

Before you grant permissions for public or cross-account access in AWS, we recommend that you verify if such access is required. You can use IAM Access Analyzer to help you preview and analyze public and cross-account access for supported resource types. You do this by reviewing the findings that IAM Access Analyzer generates. These findings help you verify that your resource access controls grant the access that you expect. Additionally, as you update public and cross-account permissions, you can verify the effect of your changes before deploying new access controls to your resources. IAM Access Analyzer also monitors supported resource types continuously and generates a finding for resources that allow public or cross-account access. For more information, see Previewing access with IAM Access Analyzer APIs.

Use IAM Access Analyzer to validate your IAM policies to ensure secure and functional permissions

Validate the policies you create to ensure that they adhere to the IAM policy language (JSON) and IAM best practices. You can validate your policies by using IAM Access Analyzer policy validation. IAM Access Analyzer provides more than 100 policy checks and actionable recommendations to help you author secure and functional policies. As you author new policies or edit existing policies in the console, IAM Access Analyzer provides recommendations to help you refine and validate your policies before you save them. Additionally, we recommend that you review and validate all of your existing policies. For more information, see IAM Access Analyzer policy validation. For more information about policy checks provided by IAM Access Analyzer, see IAM Access Analyzer policy check reference.

Establish permissions guardrails across multiple accounts

As you scale your workloads, separate them by using multiple accounts that are managed with AWS Organizations. We recommend that you use Organizations service control policies (SCPs) to establish permissions guardrails to control access for all IAM users and roles across your accounts. SCPs are a type of organization policy that you can use to manage permissions in your organization at the AWS organization, OU, or account level. The permissions guardrails that you establish apply to all users and roles within the covered accounts. However, SCPs alone are insufficient to grant permissions to the accounts in your organization. To do this, your administrator must attach identity-based or resource-based policies to IAM users, IAM roles, or the resources in your accounts. For more information, see AWS Organizations, accounts, and IAM guardrails.

Use permissions boundaries to delegate permissions management within an account

In some scenarios, you might want to delegate permissions management within an account to others. For example, you could allow developers to create and manage roles for their workloads. When you delegate permissions to others, use permissions boundaries to set the maximum permissions that you delegate. A permissions boundary is an advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM role. A permissions boundary does not grant permissions on its own. For more information, see Permissions boundaries for IAM entities.