Cloud Security Service Provider in India – Penetration Testing Service by ICSS
Cloud security service provider in India is what enterprises are looking for as moving your infrastructure to the cloud can create security problems. Indian Cyber Security Solutions cloud penetration testing services helps to identifies vulnerabilities in your cloud infrastructure and guides you on how to improve your cloud security posture. ICSS cloud security as a service aims at providing security assessments & consulting services that can guide you through the security hazards of cloud adoption. In-depth approach of our security team will help the enterprise to understand the security posture of the organizations cloud infrastructure hosted on platforms like Amazon Web Services, Microsoft Azure & Google Cloud.
ICSS Cloud Security Program
Indian Cyber Security Solutions cloud security program that we propose to clients seeks to address these challenges where as ensuring that businesses do not perceive security as a bottleneck.
- Understand the current computing landscape of the enterprise
- Understand the digital transformation roadmap
- Analyze through the use nof tools and interviews the extent of Shadow IT within the enterprise
- Understand the legal regulatory environment that impacts security and compliance requirements
- Create a cloud security policy that lays down the rules for cloud adoption by the business
- Evangelize the policy highlighting the risks and benefits of cloud computing
- Create a cloud risk assessment framework for different cloud computing models (IaaS, PaaS, and SaaS)
- Design secure data transfer, cloud connectivity, and secure access solutions for cloud computing
- Implement security monitoring and continuous auditing mechanisms for cloud environments
- Implement a managed services security program that addresses the cloud computing environment of the client
- Continuous or periodic vulnerability assessments
- Continuous security monitoring and incident response
- Implementation of DevSecOps for application security
- Designing and implementing a cloud security metrics program
Fill Up Details
Cloud Penetration Testing Services
Cloud penetration tests are often the only way to be 100% sure a system is as robust as its methodologies claim. Indian Cyber Security Solutions offers a suite of cloud penetration testing services options to identify vulnerabilities and ensure that patches are providing the protection you require.
Security experts can highlight the weaknesses that exist in current deployments and provide a full plan of attack for resolving issues and maintaining security, with multiple avenues for cloud Penetration Tests to prepare for multiple intrusion attempts and harden your security where needed.
Ask us today for a complete cloud vulnerability assessment to review your services, your servers and the applications you use. It’s time to remove any gaps that could be putting you at risk right now.
Benefits of Cloud Security Test
Cloud Security as a Service – An approach towards Penetration Testing
Cloud Security as a service by Indian Cyber Security Solutions providing penetration testing on the applications hosted on the clouds and providing real time threat mapping and mitigation. The growth of cloud has led to some interesting angles on pen testing. Cloud-based applications need to be pen tested, as do their on premises counterparts. However, pen testing applications that run in public clouds come with some complexities you must deal with, including legal and technical obstacles. To help address the challenges, here are five steps on how to approach cloud-based pen testing. Selecting the best cloud security service provider in India can be made depending the following.
Putting private clouds aside for now, public clouds have policies related to pen testing. In many cases, you must notify the provider that you’re carrying out a test, and it puts restrictions on what you can actually do during the pen-testing process. So, if you have an application that runs on a public cloud and would like to pen test it, you’ll need to do some research first regarding the process your cloud provider recommends. Not following that process could lead to trouble. For instance, your pen test will look a lot like a DDoS attack, and it may shut down your account.
All cloud providers proactively monitor their infrastructure for anomalies. In some cases, humans may give you a call to find out what’s up. In most cases, cloud service providers have automated procedures in place that shut down the system without warning when it perceives a DDoS attack. You could come into the office the next day and find that your cloud-delivered storage systems, databases, and applications are offline, and you’ll have some explaining to do to get them back up and running.
Another problem is that of being a noisy neighbor: Your pen test could take up so many resources that it affects the others on the cloud. Public clouds are multitenant and therefore must manage resources between tenants. If your pen test saturates the system, you may get an angry call from your cloud provider asking you to knock it off, or again, it could just shut down your account.
The long and short of this is that there are rules of the road when it comes to public clouds. You have to understand the legal requirements of the pen testing, as well as policies and procedures, or else you’ll quickly find yourself off the cloud system.
Cloud Provider (AWS) Pen Testing
So you’ve been thinking about getting a Penetration Test done on your AWS environment. Great! What should that involve exactly though? There are many options available and knowing what you need will help you make your often limited security budget go as far as possible.
Broadly, there are four key focus areas for most penetration tests involving AWS:
The good news here is that by default AWS does its best to help you stay fairly secure. For example, the default “launch-wizard-#” security groups don’t let your EC2 instances receive communication from the outside world, unless you actively specify it by adding additional rules.
That said, AWS still allows you plenty of rope to hang yourself with if you‘re not careful. Classic mistakes like engineering teams changing security groups to allow all inbound access is still a problem, and the nature of DevOps means services can be coming up and down on a regular basis, not always in the knowledge of team managers.
Put simply though, there is no easier way for a hacker to compromise you than finding a simple security weakness in your internet-facing infrastructure that has been overlooked, whether that’s an exposed database, or software with known vulnerabilities. This gives attackers the maximum payoff, for the minimum effort, and so the likelihood of this happening is the highest — therefore should be your first port of call to fix.
Typically though, these types of weaknesses can be picked up easily by a vulnerability scanner, and due to the changing nature of your environment (and the new vulnerabilities being released daily); are more suited to ongoing checks than they are a penetration test, which is typically conducted only once or twice a year. Fortunately, there are plenty of solutions out there, and you should definitely be using these prior to even considering a penetration test, or you’ll be paying someone to tell you something you could already have known.
As it’s your most exposed attack surface though, you probably wouldn’t want to remove your external infrastructure from the scope of any pen-test, but you shouldn’t assign a large proportion of your budget to it if possible, and don’t expect to see many results beyond what you’ve come to expect from your vulnerability scanning tools.
Many companies who are using AWS will be using it for hosting some kind of web application(s) for their customers, employees, or partners. And as web applications are designed to be exposed by their nature, they grant attackers the second easiest way into your systems — if not developed securely. This makes them the second most important attack surface after your external infrastructure.
Examples of such attacks include the famous TalkTalk hack, where a 17-year-old customer managed to find his way into their customer database and extract millions of records.
Always consider the impact and likelihood of an attack at this layer. Whether your application is fully accessible to the public, or to a limited set of customers only should factor into your decision making. Applications with “free trials” for example would allow an attacker to sign up and start having a go. B2B services for paying customers/partners may have a lower threat profile, although still not negligible, and apps for employees lower still. On the other hand, some applications contain such sensitive information the impact may seriously outweigh the likelihood.
So depending on the risk profile of your application, you may find that if you can only afford penetration testers to do a few days work, this is highly likely where you should be looking to spend their time. While automated tools exist for this type of testing, and can be useful to cover the gap between penetration tests, nothing on the market today can replace the quality of a human tester who will understand the business logic of your application, and look for ways to impact it.
The next layer of attack is the infrastructure your application is built on. Having covered off the external infrastructure, the internal side is only accessible if an attacker already has breached your defences in some way. So the threat profile here is secondary to the previous two.
Old-school penetration tests of data centres or corporate networks often revolve around gaining a foothold, then “pivoting” from one system to another, eventually leading to full-blown compromise of administrator accounts or key systems.
This is where AWS environments can differ from more traditional penetration tests though, as the software-defined nature of AWS networks often mean that tighter controls are maintained between networks, and lateral movement is a challenge. For example, once again, the default “launch-wizard #” security groups don’t let your EC2 instances talk to each other unless you actively specify it by adding them to a VPC or by adding additional rules. However, all but the most simple of AWS accounts get away with such simple configurations, and as shown in the recent Capital One breach, it is possible for attackers to compromise IAM role credentials and use those to access resources.
Additionally, the baked-in access and security controls in AWS mean that you’re far less likely to have created environment-wide “administrator” accounts that can be compromised via any of your EC2 instances. It’s more likely that you’re using privileged AWS accounts to do this, and so an AWS Config Review can add much more value than an “internal” infrastructure test.
Similarly, while unpatched software and insecure services on internal systems can be an issue, it depends to what extent you’ve created private networks in your AWS environment, and what systems can access what others. The more complexity you have, the more an internal pentest may add value. If you’re simply running a handful of EC2’s each with their own security group, you may want to skip a traditional “internal” pen-test, and consider a config review instead.
As mentioned, out of the box AWS does a lot for you in terms of security, but an AWS config review can tell you if you’ve set things up in a robust way.
Classic examples of poor AWS config are the exposed S3 buckets you often hear of, but can also include things like admin accounts with too many users being able to access them.
Once again, this can often descend into paying someone to tell you what you already know (or could easily have found out), so it could be well worth trying out some free tools before you commission a pen-test (a quick google throws up a variety of options), as the methodology is likely the same and you may find you have to answer a lot of questions you could have just answered yourself anyway.
If though you’re not confident in the security stakes, or for compliance reasons need a third-party audit, then feel free to get in touch with one of our cyber-security specialists to discuss what we can do to help.
AWS Cloud Penetration Testing Test Cases:
- Test for Unauthenticated Bucket Access
- Test for Semi-Public Bucket access – Improper ACL permission
- Targeting and compromising AWS Access keys in git commit
- Test for Extracting keys from an EC2 instance
- Exploiting AWS Security Misconfigurations
- Testing to exploit EC2 instance
- Exploiting Internal AWS Services using Lambda backdoors
- Test for Subdomain Takeover
- Testing for AWS iam Privilege Escalation
- Test for RCE attack
- Test for AWS Role Enumeration (IAM)
- Test for EC2 service to exploit privilege escalation
- Test for AWS Iam enumeration : Bypassing CloudTrail Logging
- Test for BitBuckted Server data for credentials in AWS
- DNS rebinding to compromise the cloud environment
- Test for Change of local windows / Linux logs
- Test to Create jobs or serverless actions to add root certificates and ssh private keys to machines and users (such as AWS lambda)
- Test to Create an additional interface / assign an IP address in target network / subnet on a compromised machine (like assigning a secondary private IPv4 address or interface to an AWS EC2 instance
- Steal virtual machine images from storage accounts, analyze them for passwords, keys and certificates to access live systems (like VM VHD snapshots from storage accounts)
- Test to Gain OS level access to Instances/VMs via workload management service privileges (AWS SSM)
- Create systems management commands or abuse instance metadata for scheduled and triggered command and control (AWS systems manager, modify EC2 UserData to trigger a reverse shell)
- Test to Run or deploy a workload with an assigned/passed service or role, export instance credentials for those privileges (such as EC2 passed role and meta credentials)
- Fingerprint server and application versions and frameworks, detect sensitive PII in application logs
- Test for CSV injection in AWS CloudTrail
- Tested for AWS secrets accessible via meta-data
- Attempt load balancer MiTM for session hijacking (elb) by cloud service configuration or load balancer instance compromise
- Steal credentials from metadata of proxy or http forwarding servers (credentials in AWS meta
- Steal cloud workload credentials (AWS metadata sts or Azure Linux Agent (waagent) folder credentials)
- Steal credentials from or leverage privilege to operation of a cloud key service (aws kms, azure key vault
- Alter data in datastore for fraudulent transactions or static website compromise (s3, rds, redshift)
- Alter a serverless function, logic app or otherwise a business logic implementation for action on objective or escalation (AWS lambda orAzure logic apps)
- Alter data in local sql or mysql databases
- Operate in regions where logging is not enabled or disable global logging (like CloudTrail)
- Alter log files in a non-validated log store or disable validation (like cloud trail log validation)
- Tesed for Disable network traffic analysis / logging (VPC flowlogs)
- Tesed for Disable cloud alerting to prevent detection and response (like cloudwatch alerts, GuardDuty, Security Hub, or Azure Security Center)
- Tesed for Disable data store access logging to prevent detection and response (cloudtrain data access, s3 access logging, redshift user activity)
- Alter log retention or damage the integrity of logs (s3 lifecycle, kms decryption cmk key deletion/role privilege lockout)
- Process hooking, process injection, windows access token manipulation, leveraging misconfigured sudo capabilities
- Test to Create or reset a login, access key or temporary credential belonging to a high privilege user (like iam:CreateAccessKey, sts or iam: UpdateLoginProfile)
- Test to Change the default policy for a user or new users to include additional privileges (like setdefault-policy-version)
Data shared by you will only be used to contact you with more details. Your personal data will not be shared with any third party at any circumstances.
Fill-up the Details
Cloud provider (AZURE) Pen testing:
Azure is an ever-evolving set of cloud-based services from Microsoft, designed to provide businesses with a secure global environment for all of their workload and computing needs. It even allows them to scale out, scale up and scale down as their requirements demand. While it is Microsoft’s duty to maintain this secure infrastructure and all of its configurations against cyber attacks, your company remains responsible for protecting your own hardware, website and software applications and documents from threats. Azure penetration testing enables you to benefit from many of the advantages of traditional penetration tests while remaining in compliance with Microsoft’s requirements.
Built-in Azure Security Features:
Security concerns are a top priority for all business customers. To meet this crucial demand, the developers of Azure have included many robust host services into the framework. Any data in transit is encrypted by Azure, and your data at rest can be protected by a variety of included tools. In addition, you have access to a suite of highly effective resources such as Web Application Firewall (WAF), Network Security Groups (NSG), Azure Security Center and Log Analytics with Threat Detection. Although these features are well-documented and highly effective, you still might want to take your own additional steps to assess whether attackers can breach them. If you perform an Azure penetration test, you can receive valuable reports that specify any existing vulnerabilities and recommend solutions.
Unified Rules of Engagement for Azure Penetration Testing
Microsoft has set forth a number of protocols that you must follow if you choose to conduct Azure penetration testing. The goal is to allow you to assess the security of the cloud-based services that Microsoft is hosting for you without negatively impacting any other customers running applications on the service. Should you encounter a computer security vulnerability, you must report it to Microsoft within 24 hours. As of June 15, 2017, you are no longer required to notify Microsoft that you will be performing an Azure penetration test. However, you are still prohibited from the following activities during your test:
As long as you and your team keep these rules of engagement at the top of your mind as you run the penetration testing process, you will be able to glean a great deal of useful information without running afoul of Microsoft policies.
Protect Your Web Application and Cloud Assets Today:
Safeguarding your proprietary content that lies within the Azure platform while remaining in compliance with Microsoft’s policies is both crucial and challenging. That is why many organizations choose to do their research and become a customer of a penetration testing firm.
Professionals with credentials in this constantly evolving field have expertise in the complex set of best practices and compliance requirements in the Azure ecosystem and can contribute this knowledge to your IT team throughout every step of the penetration test engagement. To open a dialogue with these testing professionals, all that is required is that you complete a simple online form. You will soon be contacted by a customer care representative who can provide you with an introduction to the available services and can help you to set up an account as well.