Blogs by Ashwin

  To read part 1, please click  here When to Create an IAM User (Instead of a Role) You need not to create an IAM user every time you need credentials as it's just an identity with specific permissions in your account, while you can simply take advantage of the IAM roles and their temporary security credentials without using them for a long-term basis. You created an AWS account and you are the only person who works in your account. Although you can easily work with AWS using root user credentials for your AWS account, it's not recommended. You should create your own IAM user and use its credentials whenever you work with AWS. Other people in your user group need to work in your AWS account, and your user group is using no other identity mechanism. You have to create IAM users for all the individuals that requires access to your AWS resources and assign them appropriate permissions along with their own credentials. You should never share credentials among multiple users. When t

  To read part 2, please click  here AWS Account Root User As stated before, whenever an AWS account is created, a single sign-in identity called the AWS account root user is provided that has complete access to all the AWS services as well as the resources in the account. It can also be accessed by signing in via the same email address and password that were used in the beginning to create the account. Note: It is strongly recommended to not use the root user for your everyday tasks, instead, the root user credentials must be locked away securely and should only be used to perform a few account and service management tasks. IAM Users It's an entity that can be created in AWS which also represents the person or service who uses the IAM user to interact with AWS. A user in AWS mainly consists of a name, a password to sign into the AWS management console, and up to two access keys that can be used with the API or CLI. Its primary purpose is to enable the people to successfully sign i

  My Credentials Aren't Working? If you can't sign-in to the AWS Management Console, and also can't remember how you accessed it before, then, there are chances that you might have accessed AWS without the credentials which is very common for enterprise single sign-on via IAM Identity Center.  AWS Access Portal- If you are allowed to use AWS credentials from outside to access it, then, you should know the URL for your portal and to look for it, you must check your email, browser favorites, or browser history for URL containing awsapps..com/start or signin.aws/platform/login. However, if you do remember your password, then, you might be on the wrong page: Root user sign-in page- You can enter your account email address in the AWS Management Console if you have to perform any kind of restricted actions within your own or created AWS account. You can also look for Signing-in as the root user in the AWS Sign-in User Guide in order to learn accessing the root user and also if yo

  Find Your AWS Account ID The following methods might help you in this: Finding your account ID using the console- You can select Support and then Support Center (in the navigation bar) where your currently signed-in 12 digit account number appears in the navigation pane. Finding your account ID using the AWS CLI- The command aws sts get-caller-identity can be used to view your user ID, account ID, and user ARN. Finding your account ID using the API- The API GetCallerIdentity can help in viewing the of your user ID, account ID, and user ARN.  About Account Aliases An account alias can be easily created if you want to change the sign-in page's URL (which is by default AWS account ID),  into your company's name or any other friendly identifier. As you can see, your sign-in page URL looks like this👇by default: https://Your_Account_ID.signin.aws.amazon.com/console/ And if you want to create an AWS account alias, then, your sign-in page URL may look like the following example: htt

  Sign in As the Root User You must know the following information before signing-in to an AWS account: Requirements- The email address used to create the AWS account. The password for the root user. To sign in to an AWS account as the root user: Firstly, open https://console.aws.amazon.com/. The main sign-in page will appear as saying select the Root user, enter the email address linked to your account, and then select Next. Now you can enter your password and sign-in. Sign-in as an IAM User As seen above, for this one also, you must have the following information: Requirements: One of the two- the account alias or the 12 digit AWS account ID. User name for your IAM user. Password for your IAM user. A root user or an IAM administrator should either provide the AWS account ID or an AWS account alias to an IAM user while an IAM user can easily log in either with a sign-in URL or the main sign-in page. To sign in to an AWS account as an IAM user using an IAM user's sin-in URL   Open

  Creating a Delegated IAM User & User Group (Console) AWS Management Console can be used to create an IAM user group with delegated permissions followed by an IAM user for another person with the help of following steps: First of all, you have to sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/. Select Policies present in the navigation pane on the left. Now, Create Policy . After that, the JSON tab and Import managed policy will be chosen. In order to minimize the list of policies, you can type Power within the Import managed policies  window, and then select the PowerUserAccess row. Now, choose Import , that will show the policy in the JSON tab. Choose Next: Tags and then Next: Review . Next, you have to type - PoweruserExampleCorp for Name and Allows full access to all s ervices except those for user management for Description , on the Review policy page, and then pick Create policy to save your work.  After succes

  Creating Your First IAM Admin User & User Group As we all know, we must not use the AWS account root user when it's not necessary, instead a new IAM user should be created for everyone who needs an administrator access.  After that these users will be made Administrators by simple putting them into an "Administrators" user group attached with an AdministratorAccess policy.  Now these users can set up the user groups, users, etc. for the AWS account to help with all the future interactions via their own keys not via root user. However, you will still require to login via root user credentials for certain accounts and service management tasks. Creating an Administrator IAM User & User Group (Console) In order to do so, you will have to follow these steps: Sign in to the IAM console via root user and insert your AWS account email address and password. Now, enable access to the billing data for the IAM admin user that can be created as follows: Select you account na

  Overview AWS IAM offers secured control and access to your AWS and account resources while simultaneously keeping your account credentials private. As a well known fact IAM offers you a variety of advantages while without it, you either have to create an AWS account or the security credentials of an AWS account should be shared by your employees; moreover, you also can't control the tasks a particular user can do via particular AWS resources. Using IAM to Give Users Access to Your AWS Resources The following measures can be taken to control access to your AWS resources: Type of Access Why would I use it? Access for users in your AWS account. If you want to add/create users via IAM and manage their permissions. Non-AWS user access via identity federation between your authorization system and AWS. If you have non-AWS users who requires access to your AWS resources. Cross-account access between AWS

  Policies & Accounts If a single account is managed in AWS, then, the permissions can be easily defined via policies, whereas, it's very difficult to manage permissions for multiple accounts and might require IAM roles, resource-based policies, or Access Control Lists (ACLs) to manage the cross-account permissions. However, it's recommended to allow the use of AWS organizations service to manage the multiple accounts' permissions.  Policies & Users IAM users are actually the identities in the service and once created, they can't access anything until they are given permissions to do that via a created identity-based policy attached with the user or a group to which the user belongs. Hence, the actions or resources that are not permitted are denied by default. Policies & Groups Another way is to organize the IAM users into IAM groups and then attach a policy to it, which will allow the individual users to have their own credentials as well as all the permiss

  First Time Access Only: Your Root User Credentials As we all know, while creating an AWS account, a one sign-in account called  root user  (having total access over all the AWS services and resources available in the account) is accessed via the email address as well as the password used while creating the account. this combination of the email address and password is also termed as Root User Credentials. Since Root User Credentials offers unrestricted access to all the AWS resources (which also includes your billing information and permission to change the password), it's strongly recommended to not use them on regular basis and/or share them with anyone. Only Service Control Policies (SCPs) in organizations can restrict the permissions that are granted to the root user. IAM Users The term referred to as authentication helps you in providing the "identity" of the user of IAM. Hence, you can also create your own users (that corresponds to users within your account) with

  Overview As IAM offers the infrastructure essential to control the authentication and authorization of an account, its elements given below should also be understood by everyone.  Principal It is a person or application that can make a request for an action or operation on an AWS resource because it is authenticated as the AWS account Root User or an IAM entity to do that. As stated before, it's strongly recommended to not use the root user credentials on daily basis, instead, create different IAM entities or support federated users or programmatic access to allow an application to access the AWS account. Request Whenever a Principal uses the AWS Management Console, API, or CLI, a request is sent to AWS which includes the following information-   Actions or Operations- The actions or operations to be done for the principal can be an action in the AWS Management Console, or an operation in AWS CLI or AWS API. Resources- The resource object on which the actions or operations are pe

  What's IAM? It is a kind of web service that can help you in accessing AWS resources securely by controlling the overall authentication and authorization. When creating an AWS account, a one sign-in account called root user (having total access over all the AWS services and resources available in the account) is accessed via the email address as well as the password used while creating the account. However, it is strongly recommended to use the root user credentials for the tasks that can only be performed by it.  IAM Features Some of the important features are as follows: Shared Access to Your AWS Account- Other people can also be given the permission to administer as well as use resources available in an AWS account without sharing any information regarding the access key or password. Granular Permissions- Different permissions can be granted to different people for different resources. Secure Access to AWS Resources for Applications that Run on Amazon C2- IAM features can also

  Cost Management Cost management is an integral part of an organization's risk management where Microsoft Sentinel creates analytic rules for detecting an attacker's behavior with the help of the data provided to it. However, every bite of the data ingested into Log Analytics carries a cost which implies that one should come up with some knowledge or ideas to build as well as evaluate a business case for adopting Microsoft Sentinel. Some of them are discussed below: Evaluating Your Data Ingestion Against Use Cases- A cost-effective analysis is highly required for the ingestion of different types of log data that may lead to extra costing in your Microsoft Sentinel deployment. It is recommended to recognize the high business risk applications with the of project teams that can survey and easily analyze the log volume or anticipated risk mitigation. Naturally, a high volume of log data with a relatively small number of potential risk issues can be excluded from Microsoft Sentine

z  To read part 1, please click  here To read part 2, please click  here To read part 3, please click  here Deploying MMAs Generally, MMA accumulates Windows Security, application, and system event logs along with the web server logs from Microsoft IIS and by deploying MMA on Linux will help in the collection of any syslog message or local logs that follows a consistent naming convention. In fact, any Linux agent installed with MMA can itself act as a syslog collector for the remote syslog log resources.  Deploying Workbooks Microsoft Sentinel workbooks offers various functions/applications like several visualization control, conditional formatting, several features of the analytical platform, etc. while it's also capable in retrieving data from multiple sources that might help in the complex integration of various Microsoft services, such as- Azure Log Analytics Workspace, Microsoft Graph, Azure Data Explorer, Azure Resource Manager, and whatnot.  Deploying User & Entity Behav

  To read part 1, please click  here To read part 2, please click  here To read part 4, please click  here Deploy After successfully completing the high-level designing, the initiation of the provisioning of the Microsoft Sentinel and its related resources can begin without any delay. Azure Resources The following resources are required by the Microsoft Sentinel: Subscription (if a dedicated subscription will be used) Resource group(s) Log Analytics workspace Automation rules/playbook Alert Rules Workbooks  However, besides Azure region, some of the other configurations like log retention, selection of a pricing model, etc. are also required during deployment. Deployment Methods These are of two types: Manual- As the name suggests, the administrator configures the Microsoft Sentinel resources manually with the help of Azure portal. However, like every other manual process, this one is also packed with the inherent risks of human operator error, lack of compliance with potential change

  To read part 1, please click  here To read part 3, please click  here To read part 4, please click  here Design Planning Architectural Planning & Considerations Some of the factors that can majorly affect the initial architecture used for the deployments of new Microsoft Sentinel instances or the migration from the existing SIEM platforms, are as follows: Data Residency Requirements- Organizations may have certain compliance restrictions regarding logged data (which are not always very clear) depending on the type of business and customer residency. They can also choose local regions according to the charges as well as the available resources in order to avoid any kind of complications due to the legislation changes or auditing processes. Regions like East U.S. can offer a significant cost advantages as compared to the other regions. Number of Azure Active Directory Tenants- As Azure AD offers Identity and Access Management (IAM) capabilities to the applications and resources of

  To read part 2, please click  here To read part 3, please click  here To read part 4, please click  here Here is an overview of the approaches that can be used in a new Microsoft Sentinel environment. Project Resourcing Project Planning some of the key factors that should be considered during a project planning stage are: Access to log sources and users. Types of log sources (standard data connectors vs required development). Complexity of Azure architecture. Requirement for custom SOAR automation playbooks. Azure cost assessment and optimization. The following roles are needed for a successful Microsoft sentinel deployment: Project Manager- It is recommended to have an experienced Project Management staff having Project Management Professional (PMP) and Information Technology Infrastructure Library (ITIL) backgrounds, as the stakeholder management requirements are quite broad.  Security Architect- As Microsoft Sentinel environment always contain highly sensitive data, the security a