Chief Architect - Uptycs Platform/Enterprise Architect - EBSCO Consulting Software Engineer - Onshape DMTS - Verizon/CloudSwitch Principal Software Engineer - RSA
Long-term cloud credentials are oftentimes (intentionally or accidentally) littered in source code, laptops/desktops, servers, cloud resources, etc. It’s easy for credentials to be copied across machines, creating sprawl that is at best, difficult to manage and at worst, unnecessarily increasing leakage risk. Furthermore, these types of credentials are only necessary when non-cloud infrastructure resources need to communicate with cloud resources; for example, data center servers trying to use AWS S3 bucket. Generally speaking, there is no good reason to have long term credentials anywhere else—employees should instead use temporary credentials by authenticating with the SSO service.
Osquery has made a tremendous positive impact in the fields of operating system observability and security analytics. It is widely used for fleet management, incident response, real-time monitoring, and for numerous other cases. While osquery became a de facto standard for IT and security teams in many organizations, Kubernetes (K8s) was emerging as a popular platform for containerized application orchestration and deployment.
Organizations should transition EC2 instances to use Instance Metadata Service Version 2 (IMDSv2) because IMDSv1 is susceptible to server-side request forgery (SSRF) attacks. Uptycs customers should be cautious about enabling the
curl table in osquery. Uptycs has updated our version of osquery to work with IMDSv2, and we’ve implemented a rule to help customers identify EC2 instances using the vulnerable metadata service.
SecOps and IT administrators have seen plenty of information regarding the GRUB2 BootHole vulnerability. In addition to BootHole, several low to moderate vulnerabilities were also discovered and fixed. While a key recommendation for mitigation is to install OS updates and patches, vendor patches should be carefully tested and incrementally applied to vulnerable assets. Updating the Secure Boot Forbidden Signature Database (dbx) has caused issues in the past. Initial GRUB2 patches from Red Hat caused boot issues for some RHEL and CentOS machines.