Seagate Shipping 32TB HAMR Hard Drives for Server, NAS, & Surveillance Markets

Post Syndicated from Ryan Smith original https://www.servethehome.com/seagate-shipping-32tb-hamr-hard-drives-for-server-nas-surveillance-markets/

Seagate has announced this week that it has begun shipping 32TB versions of its high-capacity, high-end hard drives. The second wave of hard drives based on Seagate’s heat-assisted magnetic recording (HAMR) technology, the 32TB drives mark the first capacity bump for Seagate’s top-capacity drives since Seagate brought HAMR-based drives to the retail market last year. […]

The post Seagate Shipping 32TB HAMR Hard Drives for Server, NAS, & Surveillance Markets appeared first on ServeTheHome.

Нов договор с Майкрософт или търсене на алтернативи?

Post Syndicated from Bozho original https://blog.bozho.net/blog/4561

Предстои нов договор с Майкрософт за държавната администрация. На фона на централните политически събития и многото комуникационен шум, на заден план остана решението на Министерския съвет да възложи на министъра на електронното управление да проведе обществена поръчка за продукти на Майкрософт.

Преди да отворя темата за офис пакета, трябва да уточня две неща: 1) държавната администрация ползва много продукти на Microsoft, чието лицензиране и поддръжка трябва да уреди – Windows Server, SQL Server и др. Това не е офис пакета и там дори да имаме технологични спорове за Windows vs Linux и за най-удачния избор за системи за бази данни, безпорна е нуждата от поддръжка. и 2) Microsoft е компания с добра репутация и големи и компетентни партньорски мрежи, което осигурява достатъчни гаранции за администрацията, че няма да бъде оставена да се оправя сама (което тя не може).

След тези уточнения, да минем на темата с офис пакета. Microsoft от много години предлага Office365 – облачен офис, при който Word, Excel и PowerPoint продължават да работят локално, но имат и функционалности за споделяне и колаборация, които пък изискват облачна интеграция. Предлага и централизирано управление на имейл. В частния сектор съм бил клиент на Office365, и той спестява много главоболия и налага много добри практики, вкл. във връзка с киберсигурността. Имам и негативен опит с поддръжката в Индия, която един месец не можа да разбере какво ги питам и накрая си призна, че имат бъг, но нетният резултат е безспорно позитивен.

Но тук идва проблемът, с който се сблъсках като министър – Майкрософт изисква всички потребителски акаунти да бъдат в облачната активна директория (AzureAD/Entra). Това означава цялата държавна администрация (десетки хиляди служители) да бъдат управлявани в облака на Майкрософт. Друг проблем са данните – Microsoft не предлагаше на правителствата възможността да контролират изцяло ключовете за криптиране на данните, което значеше, че Microsoft на теория има достъп до всички данни.

През 2022 г. като министър, повдигнах тези въпроси като проблем за България, защото от гледна точка на националната сигурност и суверенитета, е дългосрочен риск да отдадем толкова много контрол на компания от трета страна. Оттогава Майкрософт въведоха повече възможности за криптиране на данните от правителства – през 2025 г. въведоха поддръжка за хибридни среди с държавна инфраструктура, което е стъпка в правилната посока.

На този фон, обаче, идва проблемът е международния наказателен съд в Хага. След като Тръмп санкционира съда в хага, достъпът до имейла (в Office365) на главния прокурор към съда е бил спрян. Майкрософт първо не коментира, а после отрича да са правили нещо нередно. Но каквато и да е реалната ситуация, администрацията на САЩ разполага с инструменти да наложи определени действия на американските технологични компании.

Друга история от 2022 г. – един от големите облачни доставчици (hyperscaler-и) разглеждаше възможност за партньорство с българското правителство. Бидейки наясно с вътрешния капацитет за поддържане на облачна инфраструктура, бях много отворен към хибридни модели, в които ползваме и дори насърчаваме инвестиции на hyperscaler-и в страната, съвместно с наша инфраструктура. За съжаление времето беше твърде кратко за се развие такова партньорство, но в рамките на една среща казах, че е изключително важно да има възможност за безпроблемна мгирация извън облака, поне на ниво виртуална машина, за да няма т.нар. vendor lock-in. Те ме увериха, че няма никакъв проблем с миграцията на виртуални машини, без да знаят, че предната вечер бях мигрирал такава, във връзка със спешното създаване на български сайт за украински бежанци и се беше оказало, че изобщо не е безпроблмно и има доста скрити пречки.

В този контекст, дългосрочното обвързване на държавата с външен доставчик на такива централни услуги, без възможност и подготовка за миграция в рамките на часове, е доста рисково. Както от гледна точка на достъпа до данните, така и от гледна точка на наличността на услулгата – ако някой може да спре от днес за утре достъпа до ключова услуга по политически причини, това е проблем.

Германия отдавна е осъзнала този проблем, поради което е създала Центъра за цифров суверенитет (ZenDIS), който разработва продукти, които немската администрация ползва и чрез които не зависи от външни доставчици. След гореописания инцидент, Международният наказателен съд в Хага мигрира от Office365 към openDesk на ZenDIS, който е изцяло с отворен код.

Нека горното да не се чете като обвинение към американските компании – не че нямам технологични критики към тях, но те предоставят добри продукти, които за съжаление никоя европейска компания не е успяла да развие и наложи в такава степен.

Но от гледна точка на дългосрочните рискове и на новата ситуация, в която партньорството между САЩ и Европа е поставено под въпрос от Белия дом, следва да оценяваме внимателно и технологичните си решения.

В решението на Министерския съвет е записано „или еквивалентни“, което позволява на МЕУ да разграничи поддръжката на съществуващи сървърни продукти от офис пакета и да помисли за отворени алтернативи, които да гарантират цифров суверенитет.

Материалът Нов договор с Майкрософт или търсене на алтернативи? е публикуван за пръв път на БЛОГодаря.

Седмицата (12–17 януари)

Post Syndicated from Йовко Ламбрев original https://www.toest.bg/sedmitsata-12-17-yanuari/

Седмицата (12–17 януари)

Едва преполовихме януари, а толкова много неща вече успяха да се случат с дата от 2026 година. Ако вече се чувствате така, сякаш сте преживели цял месец (или даже няколко месеца), това не е само ваше субективно усещане. Когато събитията връхлитат с такава честота, настоящето сякаш се компресира до миг, в който няма време за осмисляне на една новина, преди тя да бъде пометена от следващата.

И не е само времето. Дистанциите окончателно губят значението си, а икономическите и политическите трусове в различни точки на планетата резонират мигновено и едновременно в нашия дневен ред, сякаш и светът внезапно се е свил. Иран, Венецуела, Украйна, Газа, Минеаполис, Гренландия… са не твърде по-далеч от покрайнините на градовете ни и съвсем не в периферията на мислите ни.

В „Тоест“ обаче никога не се напъваме да вместим повече история в единица време, защото отдавна знаем, че това води не до по-богат опит, а до колективно задъхване и усещане, че бягаме на място, опитвайки се да догоним опашката си. Затова разглобяваме свръхнаситеното с информация ежедневие, търсейки тези парченца, които носят смисъл и имат значение за бъдещето.

А онова, което има най-голямо значение за бъдещето на всички ни тук, в България, е да разглобим и унищожим веднъж завинаги добре смазаната, но смазваща развитието на страната ни машина за избори на управляващите. Това може да стане само с невиждано и нечувано масово гласуване на предстоящите предсрочни избори. Защото иначе онези никога няма да допуснат машинно гласуване, никога няма да изпуснат контрола върху броенето, а тяхното си МВР ще продължи да си затваря очите пред изборните безобразия и купувачите на гласове. Повече по темата четете в седмичния анализ на Емилия Милчева „В броячите е силата. Не, в гражданите“.

И ето! Доживяхме и новогодишното приветствие на Е.Т. в комплект със саркастичния ѝ коментар за събитията от седмицата. Видеото съдържа нездравословни дози груба действителност. Гледайте го на своя отговорност.

Толерантни ли сме един към друг? Как мислите? Да? Не? Зависи? Адски сме толерантни!, зашеметява ни още със заглавието на статията си тази седмица Светла Енчева. За да ни довърши с анализа си на последните резултати (за 2025 г.) от ежегодното национално представително изследване на обществените нагласи спрямо ЛГБТИ хората. Е, има и някои добри новини и тенденции. Аз пък си мисля, че ако темата някой ден излезе от режима на пропагандно-политическата експлоатация, обществото ни трябва да успее да я обговори и надрасне спокойно. Дано се случи по-скоро.

С политическия си анализ тази седмица Искрен Иванов се опитва рационално да обясни последните действия на администрацията на Тръмп, които ни изглеждат откровено безумни. И безпрецедентни само на фона на днешния контекст, но не и в рамките на историческите натрупвания, които често погрешно допускаме, че са останали безвъзвратно в миналото, а може би не са. Или продължават да имат своето влияние и днес. Може да прочетете повече в статията му „Да владееш или да не владееш? Как Западът се върна към началото на XX век“.

За Тръмп и САЩ няма как да не стане дума и в новия епизод на видеопоредицата ни „Тоест разговаряме“, който ще излъчим на живо днес, 17 януари, от 16:00 часа в нашия YouTube Live. Защото събеседник на Владислав Севов ще бъде Йоанна Елми, авторка в „Тоест“ от началото на 2019 г. и водеща на рубриката „Гласовете на Америка“. В анкетата на епизода може да зададете предварителен въпрос на Йоанна и да довършите изречението „Американската мечта е…“.

Дори литературната ни колонка „На второ четене“ е уплътнена със свръхбагажа на новото трескаво ежедневие. И за съжаление – напоена с кръв. С неизбежните паралели между там и тук, тях и нас. Стефан Иванов е виновен за това – и Остап Сливински с неговия „Речник на войната“. Защото според Стефан

езикът е последното бойно поле. След като градовете са паднали, след като институциите са рухнали, след като идентичностите са разбити, остава още въпросът как ще говорим за това… Ще говорим внимателно, болезнено и честно. Ще говорим така, сякаш думите тежат. Защото тежат.

И още паралели… Този път със Сърбия, за която ни разказва италианката Джорджа Спадони в няколко статии от първо лице. Тази седмица публикувахме най-новия материал от поредицата ѝ, който е озаглавен „Какво става в Сърбия? Непредвидимото бъдеще“. Текстът завършва с констатацията, че за добро или зло друго бъдеще няма – с това разполагаме. Но го има очевидния намек, че все пак от нас зависи какво ще бъде то.

Струва ми се, че сполучливо допълнение към статията на Джорджа би било припомнянето на един кратък документален филм на вече над 20 години. Той е за един исторически импулс, изпълнен с много човешки, обикновени мечти, който сега можеше да се е превърнал в по-различно настояще, ако повече хора бяха повярвали в него и в собствените си сили за промяна.

„Няма народ, който да е направил погрешен политически избор и да не е платил цената за това“, ще чуете да казва Зоран Джинджич в този филм. Затова стига вече грешни избори!

Implementing data governance on AWS: Automation, tagging, and lifecycle strategy – Part 2

Post Syndicated from Omar Ahmed original https://aws.amazon.com/blogs/security/implementing-data-governance-on-aws-automation-tagging-and-lifecycle-strategy-part-2/

In Part 1, we explored the foundational strategy, including data classification frameworks and tagging approaches. In this post, we examine the technical implementation approach and key architectural patterns for building a governance framework.

We explore governance controls across four implementation areas, building from foundational monitoring to advanced automation. Each area builds on the previous one, so you can implement incrementally and validate as you go:

  • Monitoring foundation: Begin by establishing your monitoring baseline. Set up AWS Config rules to track tag compliance across your resources, then configure Amazon CloudWatch dashboards to provide real-time visibility into your governance posture. By using this foundation, you can understand your current state before implementing enforcement controls.
  • Preventive controls: Build proactive enforcement by deploying AWS Lambda functions that validate tags at resource creation time. Implement Amazon EventBridge rules to trigger real-time enforcement actions and configure service control policies (SCPs) to establish organization-wide guardrails that prevent non-compliant resource deployment.
  • Automated remediation: Reduce manual intervention by setting up AWS Systems Manager Automation Documents that respond to compliance violations. Configure automated responses that correct common issues like missing tags or improper encryption and implement classification-based security controls that automatically apply appropriate protections based on data sensitivity.
  • Advanced features: Extend your governance framework with sophisticated capabilities. Deploy data sovereignty controls to help ensure regulatory compliance across AWS Regions, implement intelligent lifecycle management to optimize costs while maintaining compliance, and establish comprehensive monitoring and reporting systems that provide stakeholders with clear visibility into your governance effectiveness.

Prerequisites

Before beginning implementation, ensure you have AWS Command Line Interface (AWS CLI) installed and configured with appropriate credentials for your target accounts. Set AWS Identity and Access Managment (IAM) permissions so that you can create roles, Lambda functions, and AWS Config rules. Finally, basic familiarity with AWS CloudFormation or Terraform will be helpful, because we’ll use CloudFormation throughout our examples.

Tag governance controls

Implementing tag governance requires multiple layers of controls working together across AWS services. These controls range from preventive measures that validate resources at creation to detective controls that monitor existing resources. This section describes each control type, starting with preventive controls that act as first line of defense.

Preventive controls

Preventive controls help ensure resources are properly tagged at creation time. By implementing Lambda functions triggered by AWS CloudTrail events, you can validate tags before resources are created, preventing non-compliant resources from being deployed:

# AWS Lambda function for preventive tag enforcement def enforce_resource_tags(event, context):     
	required_tags = ['DataClassification', 'DataOwner', 'Environment']          

	# Extract resource details from the event     
	resource_tags = 
event['detail']['requestParameters'].get('Tags', {})          

	# Validate required tags are present     
	missing_tags = [tag for tag in required_tags if tag not in resource_tags]          

	if missing_tags:
		# Send alert to security team
		# Log non-compliance for compliance reporting         
		raise Exception(f"Missing required tags: {missing_tags}")

	return {‘status’: ‘compliant’}

For complete, production-ready implementation, see Implementing Tag Policies with AWS Organizations and EventBridge event patterns for resource monitoring.

Organization-wide policy enforcement

AWS Organizations tag policies provide a foundation for consistent tagging across your organization. These policies define standard tag formats and values, helping to ensure consistency across accounts:

{   
    "tags": {     
        "DataClassification": {       
            "tag_key": {         
                "@@assign": "DataClassification"       
            },       
            "tag_value": {         
                "@@assign": ["L1", "L2", "L3"]       
            },       
            "enforced_for": {         
                "@@assign": [           
                    "s3:bucket",           
                    "ec2:instance",           
                    "rds:db",           
                    "dynamodb:table"         
                ]       
            }     
        }   
    } 
}

Detailed implementation guidance: Getting started with tag policies & Best practices for using tag policies

Tag-based access control

Tag-based access control gives you detailed permissions using attribute-based access control (ABAC). By using this approach, you can define permissions based on resource attributes rather than creating individual IAM policies for each use case:

{     
    "Version": "2012-10-17",     
    "Statement": [         
        {             
            "Effect": "Allow",             
            "Action": ["s3:GetObject", "s3:PutObject"],             
            "Resource": "*",             
            "Condition": {                 
                "StringEquals": {                     
                    "aws:ResourceTag/DataClassification": "L1",                     
                    "aws:ResourceTag/Environment": "Prod"                 
                }             
            }         
        }     
    ] 
}

Multi-account governance strategy

While implementing tag governance within a single account is straightforward, most organizations operate in a multi-account environment. Implementing consistent governance across your organization requires additional controls:

# This SCP prevents creation of resources without required tags 
OrganizationControls:   
	SCPPolicy:     
		Type: AWS::Organizations::Policy     
		Properties:       
			Content:         
				Version: "2012-10-17"         
				Statement:           
					- 	Sid: EnforceTaggingOnResources             
						Effect: Deny             
						Action:               
							- "ec2:RunInstances"               
							- "rds:CreateDBInstance"               
							- "s3:CreateBucket"             
						Resource: "*"             
						Condition:               
							'Null':                 
								'aws:RequestTag/DataClassification': true                 
								'aws:RequestTag/Environment': true

For more information, see implementation guidance for SCPs.

Integration with on-premises governance frameworks

Many organizations maintain existing governance frameworks for their on-premises infrastructure. Extending these frameworks to AWS requires careful integration and applicability analysis. The following example shows how to use AWS Service Catalog to create a portfolio of AWS resources that align with your on-premises governance standards.

# AWS Service Catalog portfolio for on-premises aligned resources 
ServiceCatalogIntegration:   
	Portfolio:     
		Type: AWS::ServiceCatalog::Portfolio     
		Properties:       
			DisplayName: Enterprise-Aligned Resources       
			Description: Resources that comply with existing governance framework       
			ProviderName: Enterprise IT   

# Product that maintains on-prem naming conventions and controls   
	CompliantProduct:     
		Type: AWS::ServiceCatalog::CloudFormationProduct     
		Properties:       
			Name: Compliant-Resource-Bundle       
			Owner: Enterprise Architecture       
			Tags:         
				- 	Key: OnPremMapping           
					Value: "EntArchFramework-v2"

Automating security controls based on classification

After data is classified, use these classifications to automate security controls and use AWS Config to track and validate that resources are properly tagged through defined rules that assess your AWS resource configurations, including a built-in required-tags rule. For non-compliant resources, you can use Systems Manager to automate the remediation process.

With proper tagging in place, you can implement automated security controls using EventBridge and Lambda. By using this combination, you can create a cost-effective and scalable infrastructure for enforcing security policies based on data classification. For example, when a resource is tagged as high impact, you can use EventBridge to trigger a Lambda function to enable required security measures.

def apply_security_controls(event, context):     
	resource_type = event['detail']['resourceType']     
	tags = event['detail']['tags']          

	if tags['DataClassification'] == 'L1':         
		# Apply Level 1 security controls         
		enable_encryption(resource_type)         
		apply_strict_access_controls(resource_type)         
		enable_detailed_logging(resource_type)     
	elif tags['DataClassification'] == 'L2':         
		# Apply Level 2 security controls         
		enable_standard_encryption(resource_type)         
		apply_basic_access_controls(resource_type)

This example automation applies security controls consistently, reducing human error and maintaining compliance. Code-based controls ensure policies match your data classification.

Implementation resources:

Data sovereignty and residency

Data sovereignty and residency requirements help you comply with regulations like GDPR. Such controls can be implemented to restrict data storage and processing to specific AWS Regions:

# Config rule for region restrictions 
AWSConfig:   
	ConfigRule:     
		Type: AWS::Config::ConfigRule     
		Properties:       
			ConfigRuleName: s3-bucket-region-check       
			Description: Checks if S3 buckets are in allowed regions       
			Source:         
				Owner: AWS         
				SourceIdentifier: S3_BUCKET_REGION       
			InputParameters:         
				allowedRegions:           
					- eu-west-1           
					- eu-central-1

Note: This example uses eu-west-1 and eu-central-1 because these Regions are commonly used for GDPR compliance, providing data residency within the European Union. Adjust these Regions based on your specific regulatory requirements and business needs. For more information, see Meeting data residency requirements on AWS and Controls that enhance data residence protection.

Disaster recovery integration with governance controls

While organizations often focus on system availability and data recovery, maintaining governance controls during disaster recovery (DR) scenarios is important for compliance and security. To implement effective governance in your DR strategy, start by using AWS Config rules to check that DR resources maintain the same governance standards as your primary environment:

AWSConfig:   
	ConfigRule:     
		Type: AWS::Config::ConfigRule     
		Properties:       
			ConfigRuleName: dr-governance-check       
			Description: Ensures DR resources maintain governance controls       
			Source:         
				Owner: AWS         
				SourceIdentifier: REQUIRED_TAGS       
			Scope:         
				ComplianceResourceTypes:           
					- "AWS::S3::Bucket"           
					- "AWS::RDS::DBInstance"           
					- "AWS::DynamoDB::Table"       
			InputParameters:         
				tag1Key: "DataClassification"         
				tag1Value: "L1,L2,L3"         
				tag2Key: "Environment"         
				tag2Value: "DR"

For your most critical data (classified as Level 1 in part 1 of this post), implement cross-Region replication while maintaining strict governance controls. This helps ensure that sensitive data remains protected even during failover scenarios:

Cross-Region:   
	ReplicationRule:     
		Type: AWS::S3::Bucket     
		Properties:       
			ReplicationConfiguration:         
				Role: !GetAtt ReplicationRole.Arn         
				Rules:           
					- 	Status: Enabled             
						TagFilters:               
							- 	Key: "DataClassification"                 
								Value: "L1"             
						Destination:               
							Bucket: !Sub "arn:aws:s3:::${DRBucket}"               
							EncryptionConfiguration:                 
								ReplicaKmsKeyID: !Ref DRKMSKey

Automated compliance monitoring

By combining AWS Config for resource compliance, CloudWatch for metrics and alerting, and Amazon Macie for sensitive data discovery, you can create a robust compliance monitoring framework that automatically detects and responds to compliance issues:

Figure 1: Compliance monitoring architecture

Figure 1: Compliance monitoring architecture

This architecture (shown in Figure 1) demonstrates how AWS services work together to provide compliance monitoring:

  • AWS Config, CloudTrail, and Macie monitor AWS resources
  • CloudWatch aggregates monitoring data
  • Alerts and dashboards provide real-time visibility

The following CloudFormation template implements these controls:

Resources:   
	EncryptionRule:     
		Type: AWS::Config::ConfigRule     
		Properties:       
			ConfigRuleName: s3-bucket-encryption-enabled       
			Source:         
				Owner: AWS         
				SourceIdentifier: 
S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED   

	MacieJob:     
		Type: AWS::Macie::ClassificationJob     
		Properties:       
			JobType: ONE_TIME       
			S3JobDefinition:         
				BucketDefinitions:           
				- 	AccountId: !Ref AWS::AccountId             
					Buckets:               
						- !Ref DataBucket       
				ScoreFilter:         
					Minimum: 75   

	SecurityAlarm:     
		Type: AWS::CloudWatch::Alarm     
		Properties:       
			AlarmName: UnauthorizedAccessAttempts       
			MetricName: UnauthorizedAPICount       
			Namespace: SecurityMetrics       
			Statistic: Sum       
			Period: 300       
			EvaluationPeriods: 1       
			Threshold: 3       
			AlarmActions:         
				- 	!Ref SecurityNotificationTopic       
			ComparisonOperator: GreaterThanThreshold

These controls provide real-time visibility into your security posture, automate responses to potential security events, and use Macie for sensitive data discovery and classification. For a complete monitoring setup, review List of AWS Config Managed Rules and Using Amazon CloudWatch dashboards.

Using AWS data lakes for governance

Modern data governance strategies often use data lakes to provide centralized control and visibility. AWS provides a comprehensive solution through the Modern Data Architecture Accelerator (MDAA), which you can use to help you rapidly deploy and manage data platform architectures with built-in security and governance controls. Figure 2 shows an MDAA reference architecture.

Figure 2: MDAA reference architecture

Figure 2: MDAA reference architecture

For detailed implementation guidance and source code, see Accelerate the Deployment of Secure and Compliant Modern Data Architectures for Advanced Analytics and AI.

Access patterns and data discovery

Understanding and managing access patterns is important for effective governance. Use CloudTrail and Amazon Athena to analyze access patterns:

SELECT   
	useridentity.arn,   
	eventname,   
	requestparameters.bucketname,   
	requestparameters.key,   
	COUNT(*) as access_count 
FROM cloudtrail_logs 
WHERE eventname IN ('GetObject', 'PutObject') 
GROUP BY 1, 2, 3, 4 
ORDER BY access_count DESC 
LIMIT 100;

This query helps identify frequently accessed data and unusual patterns in access behavior. These insights help you to:

  • Optimize storage tiers based on access frequency
  • Refine DR strategies for frequently accessed data
  • Identify of potential security risks through unusual access patterns
  • Fine-tune data lifecycle policies based on usage patterns

For sensitive data discovery, consider integrating Macie to automatically identify and protect PII across your data estate.

Machine learning model governance with SageMaker

As organizations advance in their data governance journey, many are deploying machine learning models in production, necessitating governance frameworks that extend to machine learning (ML) operations. Amazon SageMaker offers advanced tools that you can use to maintain governance over ML assets without impeding innovation.

SageMaker governance tools work together to provide comprehensive ML oversight:

  • Role Manager provides fine-grained access control for ML roles
  • Model Cards centralize documentation and lineage information
  • Model Dashboard offers organization-wide visibility into deployed models
  • Model Monitor automates drift detection and quality control

The following example configures SageMaker governance controls:

# Basic/High-level ML governance setup with role and monitoring SageMakerRole:   
	Type: AWS::IAM::Role   
	Properties:     
		# Allow SageMaker to use this role     
		AssumeRolePolicyDocument:       
			Statement:         
				- 	Effect: Allow           
					Principal:             
						Service: sagemaker.amazonaws.com           
					Action: sts:AssumeRole     
		# Attach necessary permissions     
		ManagedPolicyArns:       
				- 	arn:aws:iam::aws:policy/AmazonSageMakerFullAccess 

ModelMonitor:   
	Type: AWS::SageMaker::MonitoringSchedule   
	Properties:     
		# Set up hourly model monitoring     
		MonitoringScheduleName: hourly-model-monitor     
		ScheduleConfig:       
			ScheduleExpression: 'cron(0 * * * ? *)'  # Run hourly

This example demonstrates two essential governance controls: role-based access management for secure service interactions and automated hourly monitoring for ongoing model oversight. While these technical implementations are important, remember that successful ML governance requires integration with your broader data governance framework, helping to ensure consistent controls and visibility across your entire data and analytics ecosystem. For more information, see Model governance to manage permissions and track model performance.

Cost optimization through automated lifecycle management

Effective data governance isn’t just about security—it’s also about managing cost efficiently. Implement intelligent data lifecycle management based on classification and usage patterns, as shown in Figure 3:

Figure 3: Tag-based lifecycle management in Amazon S3

Figure 3: Tag-based lifecycle management in Amazon S3

Figure 3 illustrates how tags drive automated lifecycle management:

  • New data enters Amazon Simple Storage Service (Amazon S3) with the tag DataClassification: L2
  • Based on classification, the data starts in Standard/INTELLIGENT_TIERING
  • After 90 days, the data transitions to Amazon S3 Glacier storage for cost-effective archival
  • The RetentionPeriod tag (84 months) determines final expiration

Here’s the implementation of the preceding lifecycle rules:

LifecycleConfiguration:   
	Rules:     
		- 	ID: IntelligentArchive       
        	Status: Enabled       
            Transitions:         
				- 	StorageClass: INTELLIGENT_TIERING           
                	TransitionInDays: 0         
               	- 	StorageClass: GLACIER           
                	TransitionInDays: 90       
			Prefix: /data/       
			TagFilters:         
				- 	Key: DataClassification           
                	Value: L2     
   		- 	ID: RetentionPolicy       
        	Status: Enabled       
            ExpirationInDays: 2555  # 7 years       
            TagFilters:         
				- 	Key: RetentionPeriod           
                	Value: "84"  # 7 years in months

S3 Lifecycle automatically optimizes storage costs while maintaining compliance with retention requirements. For example, data initially stored in Amazon S3 Intelligent-Tiering automatically moves to Glacier after 90 days, significantly reducing storage costs while helping to ensure data remains available when needed. For more information, seeManaging the lifecycle of objects and Managing storage costs with Amazon S3 Intelligent-Tiering.

Conclusion

Successfully implementing data governance on AWS requires both a structured approach and adherence to key best practices. As you progress through your implementation journey, keep these fundamental principles in mind:

  • Start with a focused scope and gradually expand. Begin with a pilot project that addresses high-impact, low-complexity use cases. By using this approach, you can demonstrate quick wins while building experience and confidence in your governance framework.
  • Make automation your foundation. Apply AWS services such as Amazon EventBridge for event-driven responses, implement automated remediation for common issues, and create self-service capabilities that balance efficiency with compliance. This automation-first approach helps ensure scalability and consistency in your governance framework.
  • Maintain continuous visibility and improvement. Regular monitoring, compliance checks, and framework updates are essential for long-term success. Use feedback from your operations team to refine policies and adjust controls as your organization’s needs evolve.

Common challenges to be aware of:

  • Initial resistance to change from teams used to manual processes
  • Complexity in handling legacy systems and data
  • Balancing security controls with operational efficiency
  • Maintaining consistent governance across multiple AWS accounts and regions

For more information, implementation support, and guidance, see:

By following this approach and remaining mindful of potential challenges, you can build a robust, scalable data governance framework that grows with your organization while maintaining security, compliance, and efficient data operations.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

Tushar Jain
Omar Ahmed

Omar Ahmed is an Auto and Manufacturing Solutions Architect who specializes in analytics. Omar’s journey in cloud computing began as an AWS data center operations technician, where he developed hands on infrastructure expertise. Outside of work, he enjoys motorsports, gaming, and swimming.
Will Black
Omar Mahmoud

Omar is a Solutions Architect helping small-medium businesses with their cloud journey. He specializes in Amazon Connect and next-gen developer services like Kiro. Omar began at AWS as a data center operations technician, gaining hands-on cloud infrastructure experience. Outside work, Omar enjoys gaming, hiking, and soccer.
Fritz Kunstler
Changil Jeong

Changil Jeong is a Solutions Architect at Amazon Web Services (AWS) partnering with Independent software vendor customers on their cloud transformation journey, with strong interests in security. He joined AWS as an SDE apprentice before transitioning to SA. Previously served in the U.S. Army as a financial and budgeting analyst and worked at a large IT consulting firm as a SaaS security analyst.
Brian Ruf
Paige Broderick

Paige Broderick is a Solutions Architect at Amazon Web Services (AWS) who works with Enterprise customers to help them achieve their AWS objectives. She specializes in cloud operations, focusing on governance and using AWS to develop smart manufacturing solutions. Outside of work, Paige is an avid runner and is likely training for her next marathon.

Implementing data governance on AWS: Automation, tagging, and lifecycle strategy – Part 1

Post Syndicated from Omar Ahmed original https://aws.amazon.com/blogs/security/implementing-data-governance-on-aws-automation-tagging-and-lifecycle-strategy-part-1/

Generative AI and machine learning workloads create massive amounts of data. Organizations need data governance to manage this growth and stay compliant. While data governance isn’t a new concept, recent studies highlight a concerning gap: a Gartner study of 300 IT executives revealed that only 60% of organizations have implemented a data governance strategy, with 40% still in planning stages or uncertain where to begin. Furthermore, a 2024 MIT CDOIQ survey of 250 chief data officers (CDOs) found that only 45% identify data governance as a top priority.

Although most businesses recognize the importance of data governance strategies, regular evaluation is important to ensure these strategies evolve with changing business needs, industry requirements, and emerging technologies. In this post, we show you a practical, automation-first approach to implementing data governance on Amazon Web Services (AWS) through a strategic and architectural guide—whether you’re starting at the beginning or improving an existing framework.

In this two-part series, we explore how to build a data governance framework on AWS that’s both practical and scalable. Our approach aligns with what AWS has identified as the core benefits of data governance:

  • Classify data consistently and automate controls to improve quality
  • Give teams secure access to the data they need
  • Monitor compliance automatically and catch issues early

In this post, we cover strategy, classification framework, and tagging governance—the foundation you need to get started. If you don’t already have a governance strategy, we provide a high-level overview of AWS tools and services to help you get started. If you have a data governance strategy, the information in this post can assist you in evaluating its effectiveness and understanding how data governance is evolving with new technologies.

In Part 2, we explore the technical architecture and implementation patterns with conceptual code examples, and throughout both parts, you’ll find links to production-ready AWS resources for detailed implementation.

Prerequisites

Before implementing data governance on AWS, you need the right AWS setup and buy-in from your teams.

Technical foundation

Start with a well-structured AWS Organizations setup for centralized management. Make sure AWS CloudTrail and AWS Config are enabled across accounts—you’ll need these for monitoring and auditing. Your AWS Identity and Access Management (IAM) framework should already define roles and permissions clearly.

Beyond these services, you’ll use several AWS tools for automation and enforcement. The AWS service quick reference table that follows lists everything used throughout this guide.

Organizational readiness

Successful implementation of data governance requires clear organizational alignment and preparation across multiple dimensions.

  • Define roles and responsibilities. Data owners classify data and approve access requests. Your platform team handles AWS infrastructure and builds automation, while security teams set controls and monitor compliance. Application teams then implement these standards in their daily workflows.
  • Document your compliance requirements. List the regulations you must follow—GDPR, PCI-DSS, SOX, HIPAA, or others. Create a data classification framework that aligns with your business risk. Document your tagging standards and naming conventions so everyone follows the same approach.
  • Plan for change management. Get executive support from leaders who understand why governance matters. Start with pilot projects to demonstrate value before rolling out organization-wide. Provide role-based training and maintain up-to-date governance playbooks. Establish feedback mechanisms so teams can report issues and suggest improvements.

Key performance indicators (KPIs) to monitor

To measure the effectiveness of your data governance implementation, track the following essential metrics and their target objectives.

  • Resource tagging compliance: Aim for 95%, measured through AWS Config rules with weekly monitoring, focusing on critical resources and sensitive data classifications.
  • Mean time to respond to compliance issues: Target less than 24 hours for critical issues. Tracked using CloudWatch metrics with automated alerting for high-priority non-compliance events
  • Reduction in manual governance tasks: Target reduction of 40% in the first year. Measured through automated workflow adoption and remediation success rates.
  • Storage cost optimization based on data classification: Target 15–20% reduction through intelligent tiering and lifecycle policies, monitored monthly by classification level.

With these technical and organizational foundations in place, you’re ready to implement a sustainable data governance framework.

AWS services used in this guide – Quick reference

This implementation uses the following AWS services. Some are prerequisites, while others are introduced throughout the guide.

Category

Services

Description

Foundation

AWS Organizations

Multi-account management structure that enables centralized policy enforcement and governance across your entire AWS environment.

AWS Identity and Access Management (IAM)

Controls who can access what resources through roles, policies, and permissions—the foundation of your security model.

Monitoring and auditing

AWS CloudTrail

Records every API call made in your AWS accounts, creating a complete audit trail of who did what, when, and from where.

AWS Config

Continuously monitors resource configurations and evaluates them against rules you define (such as requiring that all S3 buckets much be encrypted). When it finds resources that don’t meet your rules, it flags them as non-compliant so you can fix them manually or automatically.

Amazon CloudWatch

Aggregates metrics, logs, and events from across AWS for real-time monitoring, dashboards, and automated alerting on governance non-compliance.

Automation and enforcement

Amazon EventBridge

Acts as a central notification system that watches for specific events in your AWS environment (such as when an S3 bucket has been created) and automatically triggers actions in response (such as by running a Lambda function to check if it has the required tags). Think of it as an if this happens, then do that automation engine.

AWS Lambda

Runs your governance code (tag validation, security controls, remediation) in response to events without managing servers.

AWS Systems Manager

Automates operational tasks across your AWS resources. In governance, it’s primarily used to automatically fix non-compliant resources—for example, if AWS Config detects an unencrypted database, Systems Manager can run a pre-defined script to enable encryption without manual intervention.

Data protection

Amazon Macie

Uses machine learning to automatically discover, classify, and protect sensitive data like personal identifiable information (PII) across your S3 buckets.

AWS Key Management Service (AWS KMS)

Manages encryption keys for protecting data at rest, essential for high-impact data classifications.

Analytics & Insights

Amazon Athena

Serverless query service that analyzes data in Amazon S3 using SQL—perfect for querying CloudTrail logs to understand access patterns.

Standardization

AWS Service Catalog

Creates catalogs of pre-approved, governance-compliant resources that teams can deploy through self-service.

ML Governance

Amazon SageMaker

Provides specialized tools for governing machine learning operations including model monitoring, documentation, and access control.

Understanding the data governance challenge

Organizations face complex data management challenges, from maintaining consistent data classification to ensuring regulatory compliance across their environments. Your strategy should maintain security, ensure compliance, and enable business agility through automation. While this journey can be complex, breaking it down into manageable components makes it achievable.

The foundation: Data classification framework

Data classification is a foundational step in cybersecurity risk management and data governance strategies. Organizations should use data classification to determine appropriate safeguards for sensitive or critical data based on their protection requirements. Following the NIST (National Institute of Standards and Technology) framework, data can be categorized based on the potential impact to confidentiality, integrity, and availability of information systems:

  • High impact: Severe or catastrophic adverse effect on organizational operations, assets, or individuals
  • Moderate impact: Serious adverse effect on organizational operations, assets, or individuals
  • Low impact: Limited adverse effect on organizational operations, assets, or individuals

Before implementing controls, establishing a clear data classification framework is essential. This framework serves as the backbone of your security controls, access policies, and automation strategies. The following is an example of how a company subject to the Payment Card Industry Data Security Standard (PCI-DSS) might classify data:

  • Level 1 – Most sensitive data:
    • Examples: Financial transaction records, customer PCI data, intellectual property
    • Security controls: Encryption at rest and in transit, strict access controls, comprehensive audit logging
  • Level 2 – Internal use data:
    • Examples: Internal documentation, proprietary business information, development code
    • Security controls: Standard encryption, role-based access control
  • Level 3 – Public data:
    • Examples: Marketing materials, public documentation, press releases
    • Security controls: Integrity checks, version, control

To help with data classification and tagging, AWS created AWS Resource Groups, a service that you can use to organize AWS resources into groups using criteria that you define as tags. If you’re using multiple AWS accounts across your organization, AWS Organizations supports tag policies, which you can use to standardize the tags attached to the AWS resources in an organization’s account. The workflow for using tagging is shown in Figure 1. For more information, see Guidance for Tagging on AWS.

Figure 1: Workflow for tagging on AWS for a multi-account environment

Figure 1: Workflow for tagging on AWS for a multi-account environment

Your tag governance strategy

A well-designed tagging strategy is fundamental to automated governance. Tags not only help organize resources but also enable automated security controls, cost allocation, and compliance monitoring.

Figure 2: Tag governance workflow

Figure 2: Tag governance workflow

As shown in Figure 2, tag policies use the following process:

  1. AWS validates tags when you create resources.
  2. Non-compliant resources trigger automatic remediation, while compliant resources deploy normally.
  3. Continuous monitoring catches variation from your policies.

The following tagging strategy enables automation:

{   
    "MandatoryTags": {     
        "DataClassification": ["L1", "L2", "L3"],     
        "DataOwner": "<Department/Team Name>",     
        "Compliance": ["PCI", "SOX", "GDPR", "None"],     
        "Environment": ["Prod", "Dev", "Test", "Stage"],     
        "CostCenter": "<Business Unit Code>"   
    },   
    "OptionalTags": {     
        "BackupFrequency": ["Daily", "Weekly", "Monthly"],     
        "RetentionPeriod": "<Time in Months>",     
        "ProjectCode": "<Project Identifier>",     
        "DataResidency": "<Region/Country>"   
    } 
}

While AWS Organizations tag policies provide a foundation for consistent tagging, comprehensive tag governance requires additional enforcement mechanisms, which we explore in detail in Part 2.

Conclusion

This first part of the two-part series established the foundational elements of implementing data governance on AWS, covering data classification frameworks, effective tagging strategies, and organizational alignment requirements. These fundamentals serve as building blocks for scalable and automated governance approaches. Part 2 focuses on technical implementation and architectural patterns, including monitoring foundations, preventive controls, and automated remediation. The discussion extends to tag-based security controls, compliance monitoring automation, and governance integration with disaster recovery strategies. Additional topics include data sovereignty controls and machine learning model governance with Amazon SageMaker, supported by AWS implementation examples.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

Tushar Jain
Omar Ahmed

Omar Ahmed is an Auto and Manufacturing Solutions Architect who specializes in analytics. Omar’s journey in cloud computing began as an AWS data center operations technician, where he developed hands on infrastructure expertise. Outside of work, he enjoys motorsports, gaming, and swimming.
Will Black
Omar Mahmoud

Omar is a Solutions Architect helping small-medium businesses with their cloud journey. He specializes in Amazon Connect and next-gen developer services like Kiro. Omar began at AWS as a data center operations technician, gaining hands-on cloud infrastructure experience. Outside work, Omar enjoys gaming, hiking, and soccer.
Fritz Kunstler
Changil Jeong

Changil Jeong is a Solutions Architect at Amazon Web Services (AWS) partnering with Independent software vendor customers on their cloud transformation journey, with strong interests in security. He joined AWS as an SDE apprentice before transitioning to SA. Previously served in the U.S. Army as a financial and budgeting analyst and worked at a large IT consulting firm as a SaaS security analyst.
Brian Ruf
Paige Broderick

Paige Broderick is a Solutions Architect at Amazon Web Services (AWS) who works with Enterprise customers to help them achieve their AWS objectives. She specializes in cloud operations, focusing on governance and using AWS to develop smart manufacturing solutions. Outside of work, Paige is an avid runner and is likely training for her next marathon.

Simplify network segmentation for AWS Outposts racks with multiple local gateway routing domains

Post Syndicated from Brianna Rosentrater original https://aws.amazon.com/blogs/compute/simplify-network-segmentation-for-aws-outposts-racks-with-multiple-local-gateway-routing-domains/

AWS now supports multiple local gateway (LGW) routing domains on AWS Outposts racks to simplify network segmentation. Network segmentation is the practice of splitting a computer network into isolated subnetworks, or network segments. This reduces the attack surface so that if a host on one network segment is compromised, the hosts on the other network segments are not affected. Many customers in regulated industries such as manufacturing, health care and life sciences, banking, and others implement network segmentation as part of their on-premises network security standards to reduce the impact of a breach and help address compliance requirements. Some AWS services also have network requirements that specify certain IP ranges to be used for endpoints, and may or may not support customers bringing their own IP pool (also called CoIP routing, see How to choose between CoIP and Direct VPC routing (DVR) modes on AWS Outposts rack for more information). Customers want the flexibility to use both routing modes (CoIP and DVR) on the same logical Outpost. With this new feature, AWS Outposts racks now support multiple LGW routing domains to meet subnetwork isolation and cloud service network requirements in an on-premises environment. For example, a leading automotive company deploys latency-sensitive manufacturing workloads on Outposts racks in a multi-AZ architecture for resiliency. This feature provides traffic separation between routing domains and enables both customer-owned IP (CoIP) and direct VPC routing (DVR) modes on the same logical Outpost.

In this post you will learn how to use multiple LGW routing domains on Outposts racks and considerations for implementation.

Overview

With the introduction of multiple LGW routing domains on Outposts, you can now create multiple routing domains and associate one or more VLANs with each routing domain. This allows you to integrate your Outposts rack into your existing on-premises network schema. Each LGW routing domain will have a unique LGW Virtual Interface (VIF) Group and an LGW Route Table, enabling logical network traffic isolation. You can have a mix of up to 10 active routing domains with route tables using either DVR or CoIP routing mode, and you can make changes to these routing domains as needed in a self-service fashion allowing for network flexibility as architectures are updated over time. These settings can be found in the AWS Outposts console under the Networking tab in the menu.

The following diagram shows an example of 3 VPCs, each with at least 1 subnet on the Outpost rack, and each VPC corresponds to its own routing domain. Each routing domain can then be associated with one or more VLANs, and one or more VPCs. A VPC can be associated with one or more LGW routing domain.

Architecture diagram showing 3 routing domains uplinking to an on-premises network.

Figure 1 – Architecture diagram showing 3 routing domains

Walkthrough

Before creating a LGW routing domain, first you’ll need to create an LGW VIF group and an LGW route table. A local gateway routing domain is the association of a local gateway route table and local gateway VIF group. Each VIF group can be associated with one or more VLANs, but a route table can only be associated with one VIF group.

To create a LGW VIF Group, navigate to the AWS Outposts console, go to LGW virtual interfaces groups, and select Create VIF group. Enter your VIF details which include BGP and VLAN routing information, you must create 4 LGW VIFs per VIF group.

Creating VIF group for RD1 routing domain

Figure 2 – Creating VIF group for RD1 routing domain

After creating your VIF group, create a LGW route table. You’ll have the option to use Direct VPC Routing (DVR) or Customer-owned IP address pool (CoIP) routing. If CoIP routing is selected, you’ll have the option to enter your CIDR before creating. A LGW route table’s routing mode cannot be changed after creating. However, you can disassociate a LGW route table from a VIF group and attach a new route table if you need to change the routing mode of a VIF group.

Figure 3 – Creating LGW route table for RD1 routing domain

After you’ve created your LGW route table and VIF group, you can proceed to the final step which is to create your LGW routing domain where you will associate the LGW route table and VIF group.

Create LGW routing domain form for RD1 example

Figure 4 – Creating LGW routing domain for RD1

You can view and create up to 10 active routing domains through the AWS Outposts console under the Networking tab.

Figure 5 – Local Gateway (LGW) routing domains

Considerations

  • Multiple LGW routing domains feature is only available on second-generation Outposts racks.
  • Avoid overlapping IP addresses across subnetworks and local routing domains as those can create IP routing conflicts.
  • A VIF group can only be associated to one LGW route table/routing domain at a time. A routing domain is the association of a VIF group and LGW route table.
  • LGW routing domain will allow for logical local network traffic isolation, however all traffic will still travel across your local gateway Link Aggregation Control Protocol (LACP) Link Aggregation Group (LAG) to uplink into your on-premises network.
  • Additional network isolation can be achieved through Virtual Routing and Forwarding (VRF) on Cisco platforms or Routing Instances on Juniper equipment, providing logical separation of routing tables and enabling secure multi-tenancy within the same physical infrastructure.
  • You can associate a VPC to one or more LGW routing domains. You can self-serve to change VPC association as needed. Multiple on-premises VLANs can be connected to a single routing domain.

Conclusion

This post demonstrated how to configure multiple local routing domains on Outposts racks to integrate into your on-premises network. For more information see LGW routing domains section in the AWS Outposts user guide. Reach out to your AWS account team to learn more about Outposts racks network configuration options.

In addition to multiple LGW routing domains, we have also announced several updates to Outposts in the past week to help you meet digital sovereignty and local data processing needs. To learn more, read the following announcements:

To discuss Outposts with an expert on any of these topics, submit this form.

Metasploit Wrap-Up 01/16/2025

Post Syndicated from Simon Janusz original https://www.rapid7.com/blog/post/pt-metasploit-wrap-up-01-16-2025

Persistence, dMSA Abuse & RCE Goodies

This week, we have received a lot of contributions from the community, such as h00die, Chocapikk and countless others, which is greatly appreciated. This week’s modules and improvements in Metasploit Framework range from new modules, such as dMSA Abuse (resulting in escalation of privilege in Windows Active Directory environments), authenticated and unauthenticated RCE modules, as well as many improvements and additions to the persistence modules and techniques.

New module content (13)

BadSuccessor: dMSA abuse to Escalate Privileges in Windows Active Directory

Authors: AngelBoy, Spencer McIntyre, and jheysel-r7

Type: Auxiliary

Pull request: #20472 contributed by jheysel-r7 

Path: admin/ldap/bad_successor

Description: This adds an exploit for “BadSuccessor” which is a vulnerability whereby a user with permissions to an Organizational Unit (OU) in Active Directory can create a Delegated Managed Service Account (dMSA) account in such a way that it can lead to the issuance of a Kerberos ticket for an arbitrary user.

Control Web Panel /admin/index.php Unauthenticated RCE

Authors: Egidio Romano and Lukas Johannes Möller

Type: Exploit

Pull request: #20806 contributed by JohannesLks 

Path: linux/http/control_web_panel_api_cmd_exec 

AttackerKB reference: CVE-2025-67888

Description: This adds a new module for Control Web Panel (CVE-2025-67888). The vulnerability is unauthenticated OS command injection through an exposed API. The modules require Softaculous to be installed.

Prison Management System 1.0 Authenticated RCE via Unrestricted File Upload

Author: Alexandru Ionut Raducu

Type: Exploit

Pull request: #20811 contributed by Xorriath 

Path: linux/http/prison_management_rce 

AttackerKB reference: CVE-2024-48594

Description: This adds a new module for Prison Management System 1.0 (CVE-2024-48594). The module requires admin credentials, which are subsequently used to exploit unrestricted file upload to upload a webshell.

udev Persistence

Author: Julien Voisin

Type: Exploit

Pull request: #20796 contributed by h00die 

Path: linux/persistence/udev

Description: This moves the udev persistence module into the persistence category and adds the persistence mixin.

n8n Workflow Expression Remote Code Execution

Author: Lukas Johannes Möller

Type: Exploit

Pull request: #20810 contributed by JohannesLks 

Path: multi/http/n8n_workflow_expression_rce

AttackerKB reference: CVE-2025-68613

Description: This adds a new module for n8n (CVE-2025-68613). The vulnerability is authenticated remote code execution in the workflow expression evaluation engine. The module requires credentials to create a malicious workflow that executes system commands via a JavaScript payload.

Web-Check Screenshot API Command Injection RCE

Author: Valentin Lobstein [email protected] 

Type: Exploit

Pull request: #20791 contributed by Chocapikk 

Path: multi/http/web_check_screenshot_rce 

AttackerKB reference: CVE-2025-32778

Description: Adds an exploit module for CVE-2025-32778, a command injection vulnerability in Web-Check’s screenshot API endpoint which allows unauthenticated remote code execution by injecting shell commands via URL query parameters in the /api/screenshot endpoint.

Accessibility Features (Sticky Keys) Persistence via Debugger Registry Key

Authors: OJ Reeves and h00die

Type: Exploit

Pull request: #20751 contributed by h00die 

Path: windows/persistence/accessibility_features_debugger

Description: This updates the Windows sticky keys post persistence module to use the new persistence mixin.

WMI Event Subscription Event Log Persistence

Authors: Nick Tyrer <@NickTyrer> and h00die

Type: Exploit

Pull request: #20706 contributed by h00die 

Path: windows/persistence/wmi/wmi_event_subscription_event_log

Description: Updated the Windows WMI to use a new way of managing persistence modules in Metasploit Framework. The Windows WMI module has been split into four modules, each representing their own technique.

WMI Event Subscription Interval Persistence

Authors: Nick Tyrer <@NickTyrer> and h00die

Type: Exploit

Pull request: #20706 contributed by h00die 

Path: windows/persistence/wmi/wmi_event_subscription_interval

Description: Updated the Windows WMI to use a new way of managing persistence modules in Metasploit Framework. The Windows WMI module has been split into four modules, each representing their own technique.

WMI Event Subscription Process Persistence

Authors: Nick Tyrer <@NickTyrer> and h00die

Type: Exploit

Pull request: #20706 contributed by h00die 

Path: windows/persistence/wmi/wmi_event_subscription_process

Description: Updated the Windows WMI to use a new way of managing persistence modules in Metasploit Framework. The Windows WMI module has been split into four modules, each representing their own technique.

WMI Event Subscription Logon Timer Persistence

Authors: Nick Tyrer <@NickTyrer> and h00die

Type: Exploit

Pull request: #20706 contributed by h00die 

Path: windows/persistence/wmi/wmi_event_subscription_uptime

Description: Updated the Windows WMI to use a new way of managing persistence modules in Metasploit Framework. The Windows WMI module has been split into four modules, each representing their own technique.

Linux Chmod

Author: bcoles [email protected] 

Type: Payload (Single)

Pull request: #20845 contributed by bcoles 

Path: linux/armle/chmod and linux/aarch64/chmod

Description: Adds Linux ARM 32-bit / 64-bit Little Endian chmod payloads.

Enhancements and features (7)

  • #20706 from h00die – Updated the Windows WMI to use a new way of managing persistence modules in Metasploit Framework. The Windows WMI module has been split into four modules, each representing their own technique.
  • #20751 from h00die – This updates the Windows sticky keys post persistence module to use the new persistence mixin.
  • #20785 from Chocapikk – This adds Waku framework support to the existing react2shell module. Waku is a minimal React framework which differs slightly compared to Node.js. The module maintains backward compatibility with existing Next.js targets while adding Waku support through a modular framework configuration system.
  • #20786 from zeroSteiner – This updates the module code to merge the target Arch and Platform entries into the module’s top level data. Prior to this change module developers had to define Arch and Platform entries twice, once at the module level and again per individual target. This updates over 500 modules and removes that duplication.
  • #20796 from h00die – This moves the udev persistence into the persistence category and adds the persistence mixin.
  • #20853 from zeroSteiner – Bumps metapsloit-payloads to 2.0.239.
  • #20855 from h00die – Adds additional ATT&CK references to persistence modules.

Bugs fixed (2)

  • #20738 from Shubham0699 – This fixes an issue in the bailiwicked DNS modules that was causing the module to fail with a stack trace due to a programming error.
  • #20847 from dwelch-r7 – This updates the auxiliary/scanner/ssh/ssh_login module to remove stale documentation, remove unnecessary characters that were printed in the output and update the correct documentation with the new information about key usage.

Documentation added (1)

You can always find more documentation on our docsite at docs.metasploit.com.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest. To install fresh without using git, you can use the open-source-only Nightly Installers or the commercial edition Metasploit Pro

[$] A free and open-source rootkit for Linux

Post Syndicated from daroc original https://lwn.net/Articles/1053099/

While there are several rootkits that target Linux, they have so far not fully
embraced the open-source ethos typical of Linux software.
Luckily, Matheus Alves has been working to remedy
this lack by creating

an open-source rootkit called Singularity
for Linux systems. Users who feel
their computers are too secure can install the Singularity kernel module in
order to allow remote code execution, disable security features, and hide files
and processes from normal administrative tools. Despite its many features,
Singularity is not currently known to be in use in the wild — instead, it
provides security researchers with a testbed to investigate new detection and
evasion techniques.

The collective thoughts of the interwebz