Accend Networks San Francisco Bay Area Full Service IT Consulting Company

Categories
Blogs

AWS root user best practice

A COMPREHENSIVE GUIDE TO SECURING YOUR AWS ROOT USER

At the core of your AWS account lies the root user, the ultimate authority that wields unparalleled power to control every aspect of your AWS environment. It is therefore, no exaggeration to say that the root user is the linchpin of your AWS security. Failing to secure this key account could lead to catastrophic consequences, from data breaches to financial losses, and damage to your organization’s reputation.
This article serves as your essential guide to understanding the significance of securing your AWS root user. We will explore the unique risks associated with this account, discuss best practices, and provide practical steps to ensure its robust protection. Let’s embark on this crucial voyage toward safeguarding your AWS infrastructure.

What is a root user?

When you first create an Amazon Web Services (AWS) account, you begin with a single sign-in identity that has complete access to all AWS services and resources in the account. So basically, the identity used for the account creation is the root user. You can sign in as the root user using the email address and password that you used to create the account
The root account is the most privileged AWS account; it has unrestricted access to all resources in the AWS account.

Security best practices for a root user:

Avoid the use of root account!

Surprising right? There may be two questions that instantly come up: WHY and HOW?

WHY to avoid the use of root account?

The root account is the most privileged account with all the access, and hence compromise of a root account potentially means a transfer of ownership, as the attacker has the privilege to change the root password and keep the account.
So, it is recommended to avoid/minimize the use of root account.

HOW to access the AWS Console then, if not the root account?

One can create an IAM user administrator account to manage day-to-day activities and minimize the risk associated with root account access.

IAM User Administrator Account:

Immediately after creating an AWS account, one should start by creating an IAM user account specifically designated as the administrator account. This user should have elevated permissions but not full root access. This strategy minimizes the chances of unintended actions and provides a clear audit trail for all activities.

The Role of the Admin User:

The administrator user should be responsible for the following tasks:
Regular Administrative Tasks: All routine administrative tasks, such as creating, modifying, or deleting user accounts, configuring security policies, and managing resources, should be performed through the administrator account.
Access Control: The administrator account can delegate access rights to other users or roles, ensuring proper segregation of duties and limiting the scope of each administrator’s responsibility.
Monitoring and Auditing:The administrator should regularly review logs, access history, and monitor for any unusual activities within the system, maintaining a high level of vigilance.

Using the Administrator Account:

To maintain security, administrators should use the IAM administrator account for all their day-to-day activities. Using root access should be reserved for essential system maintenance or configuration changes that cannot be accomplished through the IAM administrator account.

Setup root account usage alarms.

Using Amazon CloudWatch alarms to detect AWS Root Account usage will help you monitor AWS (root) account activities. You can identify and act on activities which can lead to unauthorised access or other security breaches.

Delete your root account access keys.

Access keys are long-term credentials for an IAM user or the AWS account root user. You can use access keys to sign programmatic requests to the AWS CLI or AWS API (directly or using the AWS SDK).

Never share your root user password or access keys with anyone

Always ensure that your root account remain to yourself.

Monitor and review root user activity

Whenever the root user password or its storage location are accessed, the event should be logged and monitored to verify that your account root user is following best practices. When the root user credentials are used, Amazon CloudWatch Application Insights and AWS CloudTrail record the activity in the log and trail.

Don't create access keys for the root user

Don’t use highly privileged credentials for programmatic access. Credentials that are stored within applications are an easily exploited attack surface.

Use a strong root user password to help protect access

Strong passwords are more difficult to guess or break using brute-force attacks. Have root user passwords follow password complexity guidelines.

Configuring Security Best Practices for the Root User:

Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/

Deleting Root Access Keys

log in as root, click in my security credentials as shown below,
For my case I don’t have any access keys for my root account since it’s not a best practice, but we will create one for this demo. Under security credentials scroll down to access keys and click create access keys.
As you can already see the red flag, Root user access keys are not recommended. Check the box down on “I understand creating is not recommended but I still want to create one” then click create access key.
There we go, access keys created and you can download the csv file
Coming back to our I am dashboard, already we can see there is a red flag. we are advised to deactivate or delete access keys for root user. We will now proceed and see how we can delete access keys for root user account.
Select the radio button under access key ID, then select action drop-down button then click deactivate. Remember you must first deactivate an access key before deleting it. When prompted proceed and click deactivate.
we have successfully deactivated our access keys. We will now proceed and delete them. Again, select the radio button next to access key Id, select the drop-down button but this time round select delete. Confirm the deletion then click delete.
We have successfully deleted our access keys.

Activating Root Account MFA

Multi-Factor Authentication (MFA) is a security system that verifies a user’s identity by requiring multiple credentials. An MFA device signature adds an extra layer of protection on top of your existing root credentials making your AWS root account virtually impossible to penetrate without the MFA generated passcode.
Logged in as root, under I am dashboard, already you can see there is a one security recommendation red flag. And the red-flag is Add MFA(Multi-Factor-Authentication) for the root user.
Install any authenticator app from the list provided here, Then logged in as root, click assign MFA as shown below.
You will be brought to assign MFA device dashboard, under MFA device name enter device name for my case, I will enter vik@root.
Under MFA device, select MFA device to use, for my case because am using an Authenticator app, I will select the radio button next to the authenticator app.
click show QR code.
Open your authenticator app on your device, select add then scan a QR code, alternatively, you can type a secrete key, but for this article, we will work with the QR code. After the scan you will be prompted on your console to fill in two consecutive codes from your MFA device. Fill them then click add MFA
MFA device assigned as you can see it on your dashboard. Clap for yourself.
Now try to login into your AWS account as root user, you’ll have to provide the MFA code as follows:

This is how you can configure Security Best Practices for the Root User and enhance the security of the AWS Account.

If you have any questions, feel free to reach out to us at sales@accendnetworks.com and we would be glad to schedule a call with you to discuss your project further. 

Thank you!  

Categories
Blogs

Zero Trust Network Access (ZTNA) Best Practices Guide

Zero Trust Network Access (ZTNA) Best Practices Deployment Guide

 

Zero Trust Network Access (ZTNA) is a holistic approach to network security that combines multiple layers of protection. It commences with robust user authentication, employs the principle of least privilege, incorporates micro-segmentation to isolate and protect critical assets, and implements continuous monitoring to detect and respond to anomalies. User and device profiling, secure access control, and context-aware policies further enhance security. Secure remote access, an application-centric approach, and the use of secure web gateways and firewalls add additional layers of defense. By adopting this comprehensive approach, organizations can significantly enhance their network security and reduce the risk of breaches and data loss.
Implementing a Zero Trust Network Access (ZTNA) solution is crucial for enhancing network security in today’s digital landscape. Here, we provide a concise summary of the best practices for ZTNA implementation, which are essential for maintaining a robust security posture.
Identifying and Verifying Users and Devices

The foundation of Zero Trust Network Access (ZTNA) lies in robust user authentication, ensuring the security in the digital realm. This security measure involves employing advanced methods, such as multi-factor authentication (MFA) or digital certificates, to unequivocally verify the identity of both users and devices. This two-fold verification process goes beyond traditional username and password authentication, substantially increasing the confidence in the system’s ability to determine the legitimacy of access requests. By utilizing MFA, users are required to provide multiple pieces of evidence to establish their identity, making it significantly more challenging for unauthorized individuals or devices to infiltrate the network.

Least Privilege Access

In the realm of network security, the principle of least privilege is a fundamental concept. It dictates that users and devices should be granted the minimum level of access necessary to carry out their respective functions. This approach plays a pivotal role in minimizing potential damage in the event of a security breach. By restricting access to only what is essential, the attack surface is significantly reduced. Even if a malicious actor manages to compromise an account or device, the extent of the damage they can inflict is curtailed, as their access is limited to a narrow scope.

Micro-Segmentation

Micro-segmentation serves as a potent safeguard within the ZTNA framework. It involves dividing the network into smaller, isolated segments or zones, effectively creating secure compartments. The primary objective is to limit lateral movement within the network. In doing so, the risk of unauthorized access to critical assets is dramatically diminished. This approach isolates and fortifies these assets, rendering them impervious to threats that may have penetrated other parts of the network. Micro-segmentation exemplifies a proactive defense strategy, ensuring that even if a breach occurs, the potential for damage is confined to a specific zone.

User and Device Profiling

In the realm of ZTNA, creating comprehensive profiles of users and devices is a fundamental practice. These profiles encompass a wealth of information, including user roles, behavior patterns, and security postures. This in-depth understanding of the entities seeking access to the network plays a vital role in effective access control. By tailoring access permissions based on these profiles, organizations can ensure that the right individuals and devices have access to the right resources, while also flagging any deviations from the norm for further investigation.

Secure Access Control

The heart of ZTNA lies in dynamic access control policies that adapt to the ever-changing landscape of network security. These policies take into account a variety of factors, such as user behavior and the prevailing risk level. This adaptive approach ensures that security policies remain effective, regardless of the evolving circumstances. Security is no longer a one-size-fits-all approach but rather a finely tuned orchestration that responds to the nuances of each access request.

Context-Aware Policies

Context-aware access policies take the security of ZTNA to a new level. These policies consider a multitude of contextual factors, including the user’s location, the time of access, and the sensitivity of the requested resource. By factoring in these variables, access decisions become more fine-grained and secure. For instance, access to sensitive data may be restricted when a user is attempting to log in from an unfamiliar location, even if their credentials are valid. These policies add an extra layer of protection, enhancing security.

Secure Remote Access

Remote access is a critical aspect of ZTNA, and the approach to it is far from traditional. Rather than relying on conventional Virtual Private Networks (VPNs), organizations are increasingly implementing alternatives such as Software-Defined Perimeters (SDPs). SDPs offer enhanced remote security by dynamically adjusting access based on user profiles and contextual factors. This adaptive approach ensures that remote access remains secure and compliant with the principles of Zero Trust.

Categories
Blogs

Cisco WebEx Hybrid Solutions

Cisco WebEx Hybrid Solutions

By connecting existing network resources and on-premises unified communications services to the Cisco WebEx cloud. More collaboration capabilities will be provided, along with consistent, unified user and administrator experiences
These days almost organizations are choosing collaboration services from the cloud but many are unable to move all their services to the cloud. WebEx Hybrid Services bring cloud and premises based services together as one solution to deliver the best calling ,meeting and messaging .
There are different scenarios for hybrid calling between WebEx Cloud and CUCM on premise

1.0 Hybrid Calling for WebEx Devices (Device Connector)

Hybrid Calling for WebEx Devices provides hybrid call functionality for devices that are added to Workspaces in Control Hub. WebEx devices are registered to the cloud, and when they are enabled with Hybrid Calling, they also connect to onpremises Unified Communication Solution.
WebEx devices in the Workspace become a part of your existing on-premises dial plan, allowing these devices to call user extensions or the PSTN, and receive incoming calls Like devices registered directly to the on premise Cisco Unified Communication Solution (CUCM).
WebEx App can also have a calling capability while WebEx APP connected to a cloud-registered WebEx device that is enabled for Hybrid Calling. At this case, Users dial directly from WebEx App and have the call take place on the WebEx device.

On-premises and cloud Requirements for Hybrid Calling for WebEx Devices.

Before configuring devices for the service, ensure to meet all the prerequisites

WebEx Devices

These devices can get on-premises and PSTN calling functionality from the Unified CM after they’re enabled for Hybrid Calling. You could check all supported devices through below link

Cisco Unified Communication on-premises Solution

WebEx Device Connector

To configure Hybrid Calling for WebEx Devices, the WebEx Device Connector Software has to be installed on Machine has network access to the Unified CM that contains configuration that you want to synchronize to WebEx cloud-registered devices in Workspaces.
The WebEx Device Connector is a lightweight piece of software that could be installed on supported Windows or MAC operating systems:

Active Hybrid calling services for organization

Hybrid Calling is a service hosted by WebEx Control Hub, Administrator of WebEx Control Hub can enable this service then add this service to WebEx cloud-registered devices.

Network requirements

Open required ports for

2.0 Hybrid Calling for Webex App (Unified CM)

This Hybrid Scenario known as Migration from Jabber to WebEx App, WebEx App can be registered directly to Cisco Unified Communications Manager call control environment (on-premises enterprise). WebEx App Users will gain all on Premises experiences like Cisco Jabber, allowing them to directly make calls in WebEx App through your Unified CM environment without linking WebEx App with Devices registered on Cloud.
Cisco Unified CM and Mobile and Remote Access (MRA) solution will be used by WebEx App for registration to calling Services on Cisco Call Manager on premise similar to Jabber.
WebEx App makes its primary connection to the WebEx cloud to get its service configuration (messaging, meetings, presence, contact lists, calling behavior, and so on), but it registered directly with on premise Cisco Call manager for calling services like Jabber.

On-premises and cloud Requirements for Hybrid Calling for WebEx App.

Cisco Unified Communication on-premises Solution

Licenses

Recommended configuration but not mandatory

3.0 Hybrid Calling Through Integration between WebEx Calling and Cisco CUCM

To allow direct dialing between phones registered to Unified CM and phones in WebEx Calling locations, the integration through SIP trunk between Cisco Call manager (on-premises calling solution) and WebEx Calling (cloud calling solution) will be required.
Also this integration is required in case of transition FROM Unified CM (on-premises calling solution) TO WebEx Calling (cloud calling solution)

Local Gateway

The local gateway is an edge device for Public Switch Telephony Network (PSTN) interworking and on premises Unified CM interworking with WebEx Calling. The local gateway can be deployed standalone or in deployments where integration into Cisco Unified Communications Manager is required.
The trunk between the local gateway and WebEx Calling is always secured using SIP TLS transport and SRTP for media between Local Gateway and the WebEx Calling Access SBC.

Hardware and Software Requirements for Local Gateway

Make sure the platform is running a supported IOS-XE release as per the

License for Local Gateways

CUBE calling licenses must be installed on the local gateway

Configuring Local Gateway on WebEx Calling

There are two options to configure the Local Gateway for your WebEx Calling trunk
WebEx Calling requires secure signaling and media. The local gateway performs the encryption, and a TLS connection must be established outbound to the cloud

Configuring Local Gateway on Cisco Unified CM

Integration between Cisco Call Manager and CUBE has to be SIP based , this integration could be secured or non

Call Routing Considerations

Calls from WebEx Calling to Unified CM

The WebEx Calling routing logic works like this: if the number that is dialed on a WebEx Calling endpoint cannot be routed to any other destination within the same customer in WebEx Calling, then the call is sent to the local gateway.

Calls From Unified CM to WebEx Calling

To enable call routing from Unified CM to WebEx Calling on Unified CM a set of routes need to be provisioned to define the set of +E.164 and enterprise numbering plan addresses in WebEx Calling

WebEx Calling Licenses

WebEx Calling provides three license types
Categories
Blogs

ClearPass Self Signed Certificate

What are Digital Certificates?

Digital certificates are a crucial component of modern cybersecurity and online authentication. They are essentially electronic documents used to verify the identity of individuals, devices, or services on the network. Digital certificates serve several important purposes, with the primary one being the assurance of the authenticity and security of online communications and transactions.

Certificate Authorities (CAs) are entities responsible for issuing digital certificates. CAs are organized into a hierarchical structure, with Root CAs positioned at the top of the hierarchy. When a Root CA signs digital certificates, it employs its private key to create digital signatures. These signatures serve as a cryptographic seal of approval, attesting to the authenticity and integrity of the certificates being signed. The signed certificates, whether they belong to intermediate CAs or end entities, inherit the trust associated with the Root CA.

Types of CAs That Sign Digital Certificates?

Certificates can be signed by one of three types of CAs:

  • Public Certificate Authority (CA)
  • Private CA
  • Self-signed certificates.

Public CA Signed Certificates are perhaps the most familiar type of digital certificate. These certificates are issued by well-known and trusted third-party Certificate Authorities. Certificates signed by Public CAs enjoy widespread recognition and trust across the internet. Web browsers and operating systems come preloaded with the root certificates of these CAs, ensuring that users won’t encounter security warnings when visiting websites secured with these certificates. Public CA certificates work seamlessly across a vast array of devices, browsers, and platforms, ensuring a consistent and secure user experience.

Private CA Signed Certificates are generated and managed by organizations for their internal use. These CAs operate within closed environments. Private CAs provide complete control over certificate issuance and management. This makes them invaluable for securing internal network resources, services, and communications. Using Private CAs can be cost-effective, especially for organizations that require multiple certificates for various internal services. There are no ongoing per-certificate fees. The main drawback of these certificates is that the private root CA must be trusted by all devices that need to build trust relation ship using these certificates.

Self-signed certificates are precisely what the name suggests—they are generated and signed by the entity for which they are intended, without the involvement of any external CA. Self-signed certificates are free to create and use, making them a budget-friendly choice for those on a tight budget. These certificates can be generated and deployed rapidly without the need for external validation, which is ideal for testing and development environments.

There are some limitations with self-signed certificates:

  • Limited Trust: Self-signed certificates are not trusted by default in most web browsers and systems. Users will often encounter security warnings when accessing services secured with self-signed certificates.
  • Security Risks: Since self-signed certificates do not undergo third-party validation, there is a higher risk of them being used maliciously or mistakenly, potentially compromising security

Follow Recommendations:

As a RADIUS server, ClearPass benefits from digital certificates for mutual authentication to ensure the security and trustworthiness of the authentication and authorization process in network environments. Mutual authentication between the RADIUS server and the client provides several crucial advantages:

  • Protection Against Impersonation: Mutual authentication using digital certificates prevents impersonation attacks. Without certificates, malicious parties could potentially impersonate either the RADIUS server or the client, leading to unauthorized access or the interception of sensitive data. Certificates verify the authenticity of both parties involved in the communication, making it significantly more difficult for attackers to impersonate them.
  • Enhanced Security: Mutual authentication significantly enhances security by requiring both the server and the client to present valid digital certificates. This means that not only does the client verify the server’s identity (as is the case with one-way authentication), but the server also verifies the client’s identity. This two-way trust ensures that only authorized and trusted parties can participate in the authentication and authorization process.
  • Protection Against Man-in-the-Middle (MITM) Attacks: Digital certificates help mitigate MITM attacks, where an attacker intercepts communications between the RADIUS server and the client. In a mutual authentication setup, an attacker would need to possess valid certificates for both the client and the server to successfully impersonate them, making MITM attacks significantly more challenging.
  • Identity Verification: Mutual authentication using digital certificates ensures that the client and the RADIUS server verify each other’s identities before proceeding with the authentication process. This adds an extra layer of assurance that the parties involved are legitimate and authorized to access the network resources.
  • Secure Key Exchange: During the mutual authentication process, the client and the RADIUS server may also exchange encryption keys securely. This is essential for establishing a secure communication channel for the exchange of sensitive data, such as usernames and passwords. Without mutual authentication, there would be a greater risk of these keys falling into the wrong hands.
  • Compliance and Security Best Practices: Many security standards and best practices recommend or require mutual authentication using digital certificates to ensure the security of network access control systems like RADIUS. This includes protocols like EAP-TLS (Extensible Authentication Protocol-Transport Layer Security), which relies on mutual authentication through certificates for secure authentication.
  • Protection of Sensitive User Data: RADIUS servers often handle sensitive user data, including usernames and passwords. Mutual authentication using digital certificates helps safeguard this sensitive information by ensuring that it is transmitted securely between trusted parties.

ClearPass Seld-Signed Certificate Renewal?

Although public or private Cas are recommended in many cases for ClearPass EAP or HTTPS services, there are cases where self-signed certificate provides some advantages like ease of generation and renewal. In this article I am explaining the steps required to renewing/issuing-a-new self-signed certificate for different ClearPass certificates:

1- Login to ClearPass Policy Manager from WebUI.

2- From the left side menu, click on administration.

3- From the “Administration” sub-menu go to Administration  Certificates  Certificate Store.

ClearPass Policy Manager

4-  From this page you can see current certificates for different usages. You can select a combination of server (if you have multiple servers in a cluster) and usage. Usage can be one of the following options in ClearPass 6.9

    1. RADIUS/EAP
    2. HTTPS(ECC)
    3. HTTPS(RSA)
    4. RadSec Server
    5. Database Server

5- Select the certificate you want to reissue/renew and verify issue and expiry dates.

6- You can export the certificate from this page, you can also view details (I suggest you capture the current details if you want the new certificate to match the current one)

7- If any certificate is about to expire, click on “Create Self-Signed Certificate”

8- Select “Server Certificate”

9-  Select the server and usage you want and fill the details (you can follow the same values as current certificate or use the values that matches your organization better). Please note:

  1. You need to provide private key password. You need to take note of this password and store it in a safe place for any future retrieval.
  2. The maximum number of days of validity is 2000 days

10- After filling all required fields, click on submit.

11- Review the new certificate. If all good click on install

12- Make sure the certificate is updated successfully. Verify new certificate details.

13- You need to repeat the same process for every certificate usage you need to renew/re-issue. You can also consider exporting and importing this same certificate to other usages.