Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/03/friday-squid-blogging-giant-squid-vs-blue-marlin.html
Epic matchup.
As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.
Read my blog posting guidelines here.
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/03/russian-cyberwarfare-documents-leaked.html
Now this is interesting:
Thousands of pages of secret documents reveal how Vulkan’s engineers have worked for Russian military and intelligence agencies to support hacking operations, train operatives before attacks on national infrastructure, spread disinformation and control sections of the internet.
The company’s work is linked to the federal security service or FSB, the domestic spy agency; the operational and intelligence divisions of the armed forces, known as the GOU and GRU; and the SVR, Russia’s foreign intelligence organisation.
Lots more at the link.
The documents are in Russian, so it will be a while before we get translations.
EDITED TO ADD (4/1): More information.
Post Syndicated from Matt Laver original https://aws.amazon.com/blogs/devops/strategies-to-optimize-the-costs-of-your-builds-on-aws-codebuild/
AWS CodeBuild is a fully managed continuous integration service that compiles source code, runs tests, and produces ready-to-deploy software packages. With CodeBuild, you don’t need to provision, manage, and scale your own build servers. You just specify the location of your source code and choose your build settings, and CodeBuild will run your build scripts for compiling, testing, and packaging your code.
CodeBuild uses simple pay-as-you-go pricing. There are no upfront costs or minimum fees. You pay only for the resources you use. You are charged for compute resources based on the duration it takes for your build to execute.
There are three main factors that contribute to build costs with CodeBuild:
Understanding how to balance these factors is key to optimizing costs on AWS and this blog post will take a look at each.
CodeBuild offers three compute instance types with different amounts of memory and CPU, for example the Linux GPU Large compute type has 255GB of memory and 32 vCPUs and enables you to execute CI/CD workflow for deep learning purpose (ML/AI) with AWS CodePipeline. Incremental changes in your code, data, and ML models can now be tested for accuracy, before the changes are released through your pipeline.
The Linux 2XLarge instance type is another instance type with 145GB of memory and 72 vCPUs and is suitable for building large and complex applications that require high memory and CPU resources. It can help reduce build time, speed up delivery, and support multiple build environments.
The GPU and 2XLarge compute types are powerful but are also the most expensive compute types per minute. For most build tasks the small, medium or large instance compute types are more than adequate. Using the pricing listed in US East (Ohio) we can see the price variance between the small, medium and large Linux instance types in Figure 1 below.
Figure 1. AWS CodeBuild small, medium and large compute types vs cost per minute
Analyzing the CodeBuild compute costs leads us to a number of cost optimization considerations.
Right sizing is the process of matching instance types and sizes to your workload performance and capacity requirements at the lowest possible cost. It’s also the process of looking at deployed instances and identifying opportunities to eliminate or downsize without compromising capacity or other requirements, which results in lower costs.
Right sizing is a key mechanism for optimizing AWS costs, but it is often ignored by organizations when they first move to the AWS Cloud. They lift and shift their environments and expect to right size later. Speed and performance are often prioritized over cost, which results in oversized instances and a lot of wasted spend on unused resources.
CodeBuild monitors build resource utilization on your behalf and reports metrics through Amazon CloudWatch. These include metrics such as
These metrics can be seen within the CodeBuild console, for an example see Figure 2 below:
Figure 2. Resource utilization metrics
Leveraging observability to measuring build resource usage is key to understanding how to rightsize and CodeBuild makes this easy with CloudWatch metrics readily available through the CodeBuild console.
If we compare the costs of arm1.small and general1.small over a ten minute period we can see that the arm based compute type is 32% less expensive.
Figure 3. Comparison of small arm and general compute types
But cost per minute while building is not the only benefit here, ARM processors are known for their energy efficiency and high performance. Compiling code directly on an ARM processor can potentially lead to faster execution times and improved overall system performance.
The ideal workload to migrate to ARM is one that doesn’t use architecture-specific dependencies or binaries, already runs on Linux and uses open-source components, for example: Migrating AWS Lambda functions to Arm-based AWS Graviton2 processors.
AWS Graviton processors are custom built by Amazon Web Services using 64-bit Arm Neoverse cores to deliver the best price performance for your cloud workloads. The AWS Graviton Fast Start program helps you quickly and easily move your workloads to AWS Graviton in as little as four hours for applications such as serverless, containerized, database, and caching.
If we compare the cost of a general1.medium Windows vs Linux compute type we can see that the Linux Compute type is 43% less expensive over ten minutes:
Figure 4. Build times on Windows compared to Linux
Migrating to Linux is one strategy to not only reduce the costs of building and testing code in CodeBuild but also the cost of running in production.
The effort required to re-platform from Windows to Linux varies depending on how the application was implemented. The key is to identify and target workloads with the right characteristics, balancing strategic importance and implementation effort.
For example, older .Net applications may be able to be migrated to later versions of .NET (previously named .Net Core) first before deploying to Linux. AWS have a Porting Assistant for .NET that is an analysis tool that scans .NET Framework applications and generates a cross-platform compatibility assessment, helping you port your applications to Linux faster.
See our guide on how to escape unfriendly licensing practices by migrating Windows workloads to Linux.
One of the dimensions of the CodeBuild pricing is the duration of each build. This is calculated in minutes, from the time you submit your build until your build is terminated, rounded up to the nearest minute. For example: if your build takes a total of 35 seconds using one arm1.small Linux instance on US East (Ohio), each build will cost the price of the full minute, which is $0.0034 in that case. Similarly, if your build takes a total of 5 minutes and 20 seconds, you’ll be charged for 6 minutes.
When you define your CodeBuild project, within a buildspec file, you can specify some of the phases of your builds. The phases you can specify are install, pre-build, build, and post-build. See the documentation to learn more about what each of those phases represent. Besides that, you can define how and where to upload reports and artifacts each build generates. It means that on each of those steps, you should do only what is necessary for the task you want to achieve. Installing dependencies that you won’t need, running commands that aren’t related to your task, or performing tests that aren’t necessary will affect your build time and unnecessarily increase your costs. Packaging and uploading target artifacts with unnecessary large files would cause a similar result.
On top of the CodeBuild phases and steps that you are directly in control, each time you start a build, it takes additional time to queue the task, provision the environment, download the source code (if applicable), and finalize. See Figure 5 below a breakdown of a succeeded build:
Figure 5. AWS CodeBuild Phase details
In the above example, for each build, it takes approximately 42 seconds on top of what is specified in the buildspec file. Considering this overhead, having several smaller builds instead of fewer larger builds can potentially increase your costs. With this in mind, you have to keep your builds as short as possible, by doing only what is necessary, so that you can minimize the costs. Furthermore, you have to find a good balance between the duration and the frequency of your builds, so that the overhead doesn’t take a large proportion of your build time. Let’s explore some approaches you can factor in to find this balance.
A common way to save time and cost on your CodeBuild builds is with build caching. With build caching, you are able to store reusable pieces of your build environment, so that you can save time next time you start a new build. There are two types of caching:
Another strategy to optimize your build time and reduce your costs is using custom Docker images. When you specify your CodeBuild project, you can either use one of the default Docker images provided by CodeBuild, or use your own build environment packaged as a Docker image. When you create your own build environment as a Docker image, you can pre-package it with all the tools, test assets, and required dependencies. This can potentially save a significant amount of time, because on the install phase you won’t need to download packages from the internet, and on the build phase, when applicable, you won’t need to download e.g., large static test datasets.
To achieve that, you must specify the image value on the environment configuration when creating or updating your CodeBuild project. See Docker in custom image sample for CodeBuild to learn more about how to configure that. Keep in mind that larger Docker images can negatively affect your build time, therefore you should aim to keep your custom build environment as lean as possible, with only the mandatory contents. Another aspect to consider is to use Amazon Elastic Container Registry (ECR) to store your Docker images. Downloading the image from within the AWS network will be, in most of the cases, faster than downloading it from the public internet and can avoid bottlenecks from public repositories.
If you are using a feature-branch approach, consider carefully which build steps and tests you are going to run on your branches. Running unit tests is a good example of what you should run on the feature branches, but unless you have very specific requirements, you probably don’t need penetration or integration tests at this point. Usually the feature branch changes often, hence running all types of tests all the time is a potential waste. Prefer to have your complex, long-running tests at a later stage of your CI/CD pipeline, as you build confidence on the version that you are to release.
It’s widely considered a best practice to avoid environment-specific code builds, therefore consider a build once, deploy everywhere strategy. There are many benefits to separating environment configuration from the build including reducing build costs, improve maintainability, scalability, and reduce the risk of errors.
Build once, deploy everywhere can be seen in the AWS Deployment Pipeline Reference Architecture where the Beta, Gamma and Prod stages are created from a single artifact created in the Build Stage:
Figure 6. Application Pipeline reference architecture
Amazon CloudWatch can be used to monitor your builds, report when something goes wrong, take automatic actions when appropriate or simply keep logs of your builds.
CloudWatch metrics show the behavior of your builds over time. For example, you can monitor:
However, you may incur charges from Amazon CloudWatch Logs for build log streams. For more information, see Monitoring AWS Codebuild in the CodeBuild User Guide and the CloudWatch pricing page.
You can create an CodeBuild build project with a set of output artifacts and publish then to S3 buckets. Using S3 as a repository for your artifacts, you only pay for what you use. Check the S3 pricing page.
Cloud security at AWS is the highest priority and encryption is an important part of CodeBuild security. Some encryption, such as for data in-transit, is provided by default and does not require you to do anything. Other encryption, such as for data at-rest, you can configure when you create your project or build. Codebuild uses Amazon KMS to encrypt the data at-rest.
Build artifacts, such as a cache, logs, exported raw test report data files, and build results, are encrypted by default using AWS managed keys and are free of charge. Consider using these keys if you don’t need to create your own key.
If you do not want to use these KMS keys, you can create and configure a customer managed key. For more information, see the documentation on creating KMS Keys and AWS Key Management Service concepts in the AWS Key Management Service User Guide.
Check the KMS pricing page.
You may incur additional charges if your builds transfer data, for example:
Here’s an Overview of Data Transfer Costs for Common Architectures on AWS.
In this blog post we discussed how compute types; build duration and use of additional services contribute to build costs with AWS CodeBuild.
We highlighted how right sizing compute types is an important practice for teams that want to reduce their build costs while still achieving optimal performance. The key to optimizing is by measuring and observing the workload and selecting the most appropriate compute instance based on requirements.
Further compute type cost optimizations can be found by targeting AWS Graviton processors and Linux environments. AWS Graviton Processors in particular offer several advantages over traditional x86-based instances and are designed by AWS to deliver the best price performance for your cloud workloads.
For further reading, see the summary of CI/CD best practices from the Practicing Continuous Integration and Continuous Delivery on AWS whitepaper, my CI/CD pipeline is my release captain and also the cost optimization pillar from the AWS Well-Architected Framework which focuses on avoiding unnecessary costs.
Post Syndicated from Sparsh Wadhwa original https://aws.amazon.com/blogs/messaging-and-targeting/whatsapp-with-amazon-pinpoint/
WhatsApp now reports over 2 billion users in 180 countries, making it a prime place for businesses to communicate with their customers. In addition to native channels like SMS, push notifications, and email, Amazon Pinpoint’s custom channels enable you to extend the capabilities of Amazon Pinpoint and send messages to customers through any API-enabled service, like WhatsApp. With these new channels, you have full control over the message delivery to the endpoints associated with each custom channel campaign.
In this post, we provide a quick overview of the features and capabilities of using a custom channel as part of campaigns. We also provide a blueprint that you can use to build your first sandbox integration with WhatsApp as a custom channel.
Note: WhatsApp is a third-party service subject to additional terms and charges. Amazon Web Services isn’t responsible for any third-party service that you use to send messages with custom channels.
Before creating your new custom channel, you must have the integration ready and an Amazon Identity and Account Management (IAM) User created with the necessary permissions. First set up the following:
In this section, you create and configure a project in Amazon Pinpoint. Later, you use this data to create segments and campaigns.
In Amazon Pinpoint, an endpoint represents a specific method of contacting a customer. This could be their email address (for email messages) or their phone number (for SMS messages) or a custom endpoint type. Endpoints can also contain custom attributes, and you can associate multiple endpoints with a single user. In this step, we create an SMS endpoint that is used to send a WhatsApp message.
To create an endpoint using AWS CLI, at the command line, enter the following command:
aws pinpoint update-endpoint –application-id <project-id> \
–endpoint-id 12456 –endpoint-request “Address='<mobile-number>’, \
ChannelType=’SMS’,Attributes={username=[‘testUser’],integrations=[‘WhatsApp’]}”
In the preceding example, replace <project-id> with the Amazon Pinpoint Project ID that you copied in step 1.
Replace <mobile-number> with your phone number with country code (for example, 12065550142). For the WhatsApp integration to work, you must use the mobile number that are registered on WhatsApp and are already verified on Meta Developer Portal (since your Meta account is currently in sandbox).
Note: WhatsApp Business Cloud message API doesn’t require ‘+’ symbol in the front of the Phone number. So in case you plan to use this segment for both SMS and Custom Channel, you may configure Phone Number in E.164 format (for example, +12065550142) and remove ‘+’ symbol in the Lambda function code that we create in the step 4.
We can securely store the WhatsApp Auth Token and WhatsApp From Number Id which we have received in the previous steps in AWS Secrets Manager.
You must create an AWS Lambda that has the code that calls Meta WhatsApp Business Cloud API and sends a message to the endpoint.
import base64
import json
import os
import urllib
from urllib import request, parse
import boto3
from botocore.exceptions import ClientError
WhatsApp_messageAPI_URL = "https://graph.facebook.com/v15.0/"
def get_secret():
secret_name = "MetaWhatsappCreds"
region_name = "us-east-1"
# Pass the required AWS Region in which Secret is stored
# Create a Secrets Manager client
session = boto3.session.Session()
client = session.client(
service_name='secretsmanager',
region_name=region_name
)
try:
get_secret_value_response = client.get_secret_value(
SecretId=secret_name
)
except ClientError as e:
# For a list of exceptions thrown, see
# https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html
raise e
# Decrypts secret using the associated KMS key.
secret = get_secret_value_response['SecretString']
return secret
def lambda_handler(event, context):
credentials = get_secret()
WhatsApp_AUTH_TOKEN = json.loads(credentials)["WHATSAPP_AUTH_TOKEN"]
WhatsApp_FROM_NUMBER_ID = json.loads(credentials)["WHATSAPP_FROM_NUMBER_ID"]
if not WhatsApp_AUTH_TOKEN:
return "Unable to access WhatsApp Auth Token."
elif not WhatsApp_FROM_NUMBER_ID:
return "Unable to access WhatsApp From Number Id."
# Lets print out the event for our logs
print("Received event: {}".format(event))
populated_url = WhatsApp_messageAPI_URL + WhatsApp_FROM_NUMBER_ID + "/messages"
for key in event['Endpoints'].keys():
to_number = event['Endpoints'][key]['Address']
# Example body and using an attribute from the endpoint
username = event['Endpoints'][key]['Attributes']['username'][0]
body = "Hello {}, here is your weekly 10% discount coupon: SAVE10".format(username)
post_params = {"messaging_product":"whatsapp","to": to_number ,"recipient_type": "individual","type": "text", "text":{"preview_url": "false","body": body}}
# encode the parameters for Python's urllib
print(post_params)
data = parse.urlencode(post_params).encode('ascii')
req = request.Request(populated_url)
req.add_header("Authorization", WhatsApp_AUTH_TOKEN )
req.add_header("Content-Type","application/json")
try:
# perform HTTP POST request
with request.urlopen(req, data) as f:
print("WhatsApp returned {}".format(str(f.read().decode('utf-8'))))
except Exception as e:
# something went wrong!
print(e)
return "WhatsApp messages sent successfully"
aws lambda add-permission \
–function-name WhatsAppTest \
–statement-id sid \
–action lambda:InvokeFunction \
–principal pinpoint.us-east-1.amazonaws.com \
–source-arn arn:aws:mobiletargeting:us-east-1:<account-id>:apps/<Pinpoint ProjectID>/*
Now that we have an endpoint, we must add it to a segment so that we can use it within a campaign. By sending a campaign, we can verify that our Amazon Pinpoint project is configured correctly, and that we created the endpoint correctly.
To create the segment and campaign:
Within a few seconds, you should receive a WhatsApp message at the phone number that you specified when you created the endpoint and verified on the Meta Developer portal.
Your Custom channel solution for WhatsApp is now ready to use. But first, review and upgrade your WhatsApp sandbox. This post is simply a walkthrough to show you how quickly you can prototype and start sending WhatsApp messages with Pinpoint and Meta. However, for production usage, you need to make sure to review all of the additional terms and charges. Start here to understand more: https://developers.facebook.com/docs/whatsapp/cloud-api/get-started
As a next steps, you can go ahead and claim a Phone number for sending WhatsApp messages in production. You can further configure a Webhook which can help you in receiving WhatsApp message delivery status and other WhatsApp supported events.
There are several ways you can make this solution your own.
Amazon Pinpoint is a flexible and scalable outbound and inbound marketing communications service. Learn more here: https://aws.amazon.com/pinpoint/
Post Syndicated from Lucas Chen original https://aws.amazon.com/blogs/devops/extending-cloudformation-and-cdk-with-third-party-extensions/
Did you know you can use CloudFormation to manage third-party resources? The AWS CloudFormation Public Registry provides a searchable collection of CloudFormation extensions and makes it easy to discover and provision them in CloudFormation templates and AWS Cloud Development Kit (CDK) applications. In the past three months, we’ve added a number of new, exciting partners to the Public Registry, including GitLab, Okta, and PagerDuty.
The extensions available on the registry are wide-ranging and include third-party resources from partners such as MongoDB; hooks, which are preventative controls that add safeguards to provisioning; and modules, which are re-usable components that take into account best practices and opinionated definitions of resources. AWS Partner Network (APN), third parties, and the developer community contribute these extensions to the Public Registry. Using extensions, customers no longer need to create and maintain custom provisioning logic for resource types from third-party vendors.
Over last few months, AWS collaborated with partners to develop and publish over 80 new resources across 14 providers to Public Registry for CloudFormation. Below is a summary of the new resource type additions.
| Provider | Use case |
| MongoDB Atlas |
Manage components in MongoDB Atlas. Add, edit, or delete administrative objects within Atlas, including projects, users, and database deployments Note: You cannot read or write data to Atlas Clusters with Atlas Admin APIs and AWS CloudFormation resources. To read and write data in Atlas, you must use the Atlas Data API |
| GitLab | Manage the users and groups in an organization, set up a new project with the right users, groups, and access token, tag a project automatically for every active CI/CD deployment |
| New Relic | Create a new Dashboard with custom Pages, Widgets and Layout, add tags to your data to help improve data organization and findability, workloads-related tasks |
| GitHub | Manage the users and groups in an organization, set up a new project with the right users, groups, and access token, Add a webhook to a repo |
| Dynatrace | Set up a new project with service level objective, locations, monitors and metrics |
| Okta | Onboard a new application into Okta with the right users and groups |
| PagerDuty | Set up monitoring of a new or existing application |
| Databricks | Set up a Databricks cluster and jobs |
| Fastly | Configure Fastly as a CDN for your web app |
| BigID | Connect S3 and DynamoDB data sources into your BigID application |
| Rollbar | Set up a new Rollbar project and manage rules, teams, and users |
| Cloudflare | Configure a DNS record and load-balancing using Cloudflare |
| Lacework | Configure Lacework alert profiles, rules, channels and manage queries |
| Snowflake | Create databases, users, and manage privileges |
Here are some of the benefits for extension builders and consumers when publishing extensions to the public registry:
We’ve seen great momentum from our partners and developer community over the past year. We are looking forward to continued investment and innovation in the Public Registry.
Third party resource types must first be activated before they can be used. You do this by logging into your AWS Console > Navigate to CloudFormation > Registry > Public extensions > Set the Publisher to Third Party. This will show you a list of available third-party resources in your region (note that different regions may have a different set of third-party resource types). Select the radio box next to the resource types you want to activate and click the activate button at the top of the list.
Figure 1:
You can submit requests for new third-party extensions through our Community Registry Extensions Github repo issue tracker! Click the New Issue button and describe the third-party extension along with information about your use case.
You can see several of the community-built registry extensions in the AWS CloudFormation Community Registry Extensions repository and even contribute yourself. You can also read about the experiences and lessons learned from publishing to the Registry through this blog written by Cloudsoft.
For developers looking to create new resource types to add to the public Registry, follow this creating resource types walkthrough help you get started. If you need assistance creating, publishing resources, or just want to join the discussion, you can join the conversation today in our CloudFormation Discord Channel. We’d love to hear about your experiences and use cases in developing innovations with registry extensions.
About the authors:
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/03/the-security-vulnerabilities-of-message-interoperability.html
Jenny Blessing and Ross Anderson have evaluated the security of systems designed to allow the various Internet messaging platforms to interoperate with each other:
The Digital Markets Act ruled that users on different platforms should be able to exchange messages with each other. This opens up a real Pandora’s box. How will the networks manage keys, authenticate users, and moderate content? How much metadata will have to be shared, and how?
In our latest paper, One Protocol to Rule Them All? On Securing Interoperable Messaging, we explore the security tensions, the conflicts of interest, the usability traps, and the likely consequences for individual and institutional behaviour.
Interoperability will vastly increase the attack surface at every level in the stack from the cryptography up through usability to commercial incentives and the opportunities for government interference.
It’s a good idea in theory, but will likely result in the overall security being the worst of each platform’s security.
Post Syndicated from Abdullahi Olaoye original https://aws.amazon.com/blogs/devops/publish-amazon-devops-guru-insights-to-servicenow-for-incident-management/
Amazon DevOps Guru is a fully managed AIOps service that uses machine learning (ML) to quickly identify when applications are behaving outside of their normal operating patterns and generates insights from its findings. These insights generated by Amazon DevOps Guru can be used to alert on-call teams to react to anomalies for mission critical workloads. Various customers already utilize Incident management systems like ServiceNow to identify, analyze and resolve critical incidents which could impact business operations. ServiceNow is an IT Service Management (ITSM) platform that enables enterprise organizations to improve operational efficiencies. Among its products is Incident Management which provides a single pane view to customers and allows customers restore services and resolve issues quickly.
This blog post will show you how to integrate Amazon DevOps Guru insights with ServiceNow to automatically create and manage Incidents. We will demonstrate how an insight generated by Amazon DevOps Guru for an anomaly can automatically create a ServiceNow Incident, update the incident when there are new anomalies or recommendations from Amazon DevOps Guru, and close the ServiceNow Incident once the insight is resolved by Amazon DevOps Guru.
This solution uses a combination of event driven architecture and Serverless technologies, to integrate DevOps Guru insights with ServiceNow. When an Amazon DevOps Guru insight is created, an Amazon EventBridge rule is used to capture the insight as an event and routed to an AWS Lambda Function target. The lambda function interacts with ServiceNow using a REST API to create, update and close an incident for corresponding DevOps Guru events captured by EventBridge.
The EventBridge rule can be customized to capture all DevOps Guru insights or narrowed down to specific insights. In this blog, we will be capturing all DevOps Guru insights and will be performing actions on ServiceNow for the below DevOps Guru events:
Figure 1: Amazon DevOps Guru Integration with ServiceNow using Amazon EventBridge and AWS Lambda
Before you deploy the solution and proceed with this walkthrough, you should have the following prerequisites:
You have two options to deploy this solution, one options is to deploy from the AWS Serverless Repository and other from the Command Line Interface (CLI).
The DevOps Guru ServiceNow Connector application is available in the AWS Serverless Application Repository which is a managed repository for serverless applications. The application is packaged with an AWS Serverless Application Model (SAM) template, definition of the AWS resources used and the link to the source code. Follow the steps below to quickly deploy this serverless application in your AWS account.
Follow the steps below to quickly deploy this serverless application in your AWS account:
Figure 2: Deploy solution through AWS Serverless Repository
Figure 3: AWS Lambda Application Settings
As you have seen above, you can directly deploy the sample serverless application from the Serverless Repository with one click deployment. Alternatively, you can choose to clone the github source repository and deploy using the SAM CLI from your terminal.
The Serverless Application Model Command Line Interface (SAM CLI) is an extension of the AWS CLI that adds functionality for building and testing serverless applications. The CLI provides commands that enable you to verify that AWS SAM template files are written according to the specification, invoke Lambda functions locally, step-through debug Lambda functions, package and deploy serverless applications to the AWS Cloud, and so on. For details about how to use the AWS SAM CLI, including the full AWS SAM CLI Command Reference, see AWS SAM reference – AWS Serverless Application Model.
Before you proceed, make sure you have completed the Prerequisites section in the beginning which should set up the AWS SAM CLI, Maven and Java on your local terminal. You also need to install and set up Docker to run your functions in an Amazon Linux environment that matches Lambda.
Follow the steps below to build and deploy this serverless application using AWS SAM CLI in your AWS account:
$ git clone https://github.com/aws-samples/amazon-devops-guru-connector-servicenow.git$ sam validate –-lint --template template.yaml3. Build the application with SAM CLI
$ cd amazon-devops-guru-connector-servicenow
$ sam buildIf everything is set up correctly, you should have a success message like shown below:
Build Succeeded
Built Artifacts : .aws-sam/build
Built Template : .aws-sam/build/template.yaml
Commands you can use next
=========================
[*] Validate SAM template: sam validate
[*] Invoke Function: sam local invoke
[*] Test Function in the Cloud: sam sync --stack-name {{stack-name}} --watch
[*] Deploy: sam deploy –guided4. Deploy the application with SAM CLI
$ sam deploy –-guidedThis command will package and deploy your application to AWS, with a series of prompts that you should respond to as shown below:
Stack Name: The name of the stack to deploy to CloudFormation. This should be unique to your account and region, and a good starting point would be something matching your project name – amazon-devops-guru-connector-servicenowAWS Region: The AWS region you want to deploy your application to.Parameter ServiceNowHost []: The ServiceNow host name/instance URL you set up. Example: dev92031.service-now.comParameter SecretName []: The secret name that you set up for ServiceNow credentials in the Prerequisites.Confirm changes before deploy: If set to yes, any change sets will be shown to you before execution for manual review. If set to no, the AWS SAM CLI will automatically deploy application changes.Allow SAM CLI IAM role creation: Many AWS SAM templates, including this example, create AWS IAM roles required for the AWS Lambda function(s) included to access AWS services. By default, these are scoped down to minimum required permissions. To deploy an AWS CloudFormation stack which creates or modifies IAM roles, the CAPABILITY_IAM value for capabilities must be provided. If permission isn’t provided through this prompt, to deploy this example you must explicitly pass --capabilities CAPABILITY_IAM to the sam deploy command.Disable rollback [y/N]: If set to Y, preserves the state of previously provisioned resources when an operation fails.Save arguments to configuration file (samconfig.toml): If set to yes, your choices will be saved to a configuration file inside the project, so that in the future you can just re-run sam deploy without parameters to deploy changes to your application.After you enter your parameters, you should see something like this if you have provided Y to view and confirm ChangeSets. Proceed here by providing ‘Y’ for deploying the resources.
Initiating deployment
=====================
Uploading to amazon-devops-guru-connector-servicenow/46bb4841f8f37fd41d3f40f86f31c4d7.template 1918 / 1918 (100.00%)
Waiting for changeset to be created..
CloudFormation stack changeset
-----------------------------------------------------------------------------------------------------------------------------------------------------
Operation LogicalResourceId ResourceType Replacement
-----------------------------------------------------------------------------------------------------------------------------------------------------
+ Add FunctionsDevOpsGuruPermission AWS::Lambda::Permission N/A
+ Add FunctionsDevOpsGuru AWS::Events::Rule N/A
+ Add FunctionsRole AWS::IAM::Role N/A
+ Add Functions AWS::Lambda::Function N/A
-----------------------------------------------------------------------------------------------------------------------------------------------------
Changeset created successfully. arn:aws:cloudformation:us-east-1:123456789012:changeSet/samcli-deploy1669232233/7c97b7f5-369d-400d-89cd-ebabefaa0b57
Previewing CloudFormation changeset before deployment
======================================================
Deploy this changeset? [y/N]:Once the deployment succeeds, you should be able to see the successful creation of your resources
CloudFormation events from stack operations (refresh every 0.5 seconds)
-----------------------------------------------------------------------------------------------------------------------------------------------------
ResourceStatus ResourceType LogicalResourceId ResourceStatusReason
-----------------------------------------------------------------------------------------------------------------------------------------------------
CREATE_IN_PROGRESS AWS::CloudFormation::Stack amazon-devops-guru-connector- User Initiated
servicenow
CREATE_IN_PROGRESS AWS::IAM::Role FunctionsRole -
CREATE_IN_PROGRESS AWS::IAM::Role FunctionsRole Resource creation Initiated
CREATE_COMPLETE AWS::IAM::Role FunctionsRole -
CREATE_IN_PROGRESS AWS::Lambda::Function Functions -
CREATE_IN_PROGRESS AWS::Lambda::Function Functions Resource creation Initiated
CREATE_COMPLETE AWS::Lambda::Function Functions -
CREATE_IN_PROGRESS AWS::Events::Rule FunctionsDevOpsGuru -
CREATE_IN_PROGRESS AWS::Events::Rule FunctionsDevOpsGuru Resource creation Initiated
CREATE_COMPLETE AWS::Events::Rule FunctionsDevOpsGuru -
CREATE_IN_PROGRESS AWS::Lambda::Permission FunctionsDevOpsGuruPermission -
CREATE_IN_PROGRESS AWS::Lambda::Permission FunctionsDevOpsGuruPermission Resource creation Initiated
CREATE_COMPLETE AWS::Lambda::Permission FunctionsDevOpsGuruPermission -
CREATE_COMPLETE AWS::CloudFormation::Stack amazon-devops-guru-connector- -
servicenow
-----------------------------------------------------------------------------------------------------------------------------------------------------
Successfully created/updated stack - amazon-devops-guru-connector-servicenow in us-east-1You can also use the below command to list the resources deployed by passing in the stack name.
$ sam list resources --stack-name amazon-devops-guru-connector-servicenowYou can also choose to test and debug your function locally with sample events using the SAM CLI local functionality. Test a single function by invoking it directly with a test event. An event is a JSON document that represents the input that the function receives from the event source. Refer the Invoking Lambda functions locally – AWS Serverless Application Model link here for more details.
Follow the below steps for testing the lambda with the SAM CLI local. You have to create an env.json file with the correct values for your ServiceNow Host and SecretManager secret name that was created in the previous step.
{"Parameters": {"SERVICE_NOW_HOST": "SNOW_HOST","SECRET_NAME": "SNOW_CREDS"}}$ sam local invoke Functions --event Functions/src/test/Events/CreateIncident.json --env-vars Functions/src/test/Events/env.jsonOnce you are done with the above steps, move on to “Test the Solution” section below to trigger sample DevOps Guru insights and validate that the incidents are created and updated in ServiceNow.
To test the solution, we will simulate a DevOps Guru insight. You can also simulate an insight by following the steps in this blog. After an anomaly is detected in the application, DevOps Guru creates an insight as seen below.
Figure 4: DevOps Guru Insight created for anomalous behavior
For the DevOps Guru insight shown above, a corresponding incident is automatically created on ServiceNow as shown below. In addition to the incident creation, any new anomalies and recommendations from DevOps Guru is also associated with the incident.
Figure 5: Corresponding ServiceNow Incident is created for the DevOps Guru Insight
When the anomalous behavior that generated the DevOps Guru insight is resolved, DevOps Guru automatically closes the insight. The corresponding ServiceNow incident that was created for the insight is also closed as seen below
Figure 6: ServiceNow Incident created for DevOps Guru Insight is resolved due to insight closure
To avoid incurring future charges, delete the resources.
To delete the sample application that you created, use the AWS CLI command below and pass the stack name you provided in the sam deploy step.
$ aws cloudformation delete-stack --stack-name amazon-devops-guru-connector-servicenowYou could also use the AWS CloudFormation Console to delete the stack:
Figure 7: AWS Stack Console with Delete action
This blog post showcased how DevOps Guru continuously monitor resources in a particular region in your AWS account and automatically detects operational issues, predicts impending resource exhaustion, details likely cause, and recommends remediation actions. This post described a custom solution using serverless integration pattern with AWS Lambda and Amazon EventBridge which enabled integration of the DevOps Guru insights with customer’s most popular ITSM and Change management tool ServiceNow thus streamlining the Service Management governance and oversight over AWS services. Using this solution helps Customer’s with ServiceNow to improve their operational efficiencies, and get customized insights and real time incident alerts and management directly from DevOps Guru which provides a single pane of glass to restore services and systems quickly.
This solution was created to help customers who already use ServiceNow Incident Management, if you are already using Incident Manager from AWS Systems Manager, check out how that works with Amazon DevOps Guru here.
To learn more about Amazon DevOps Guru, join us for a free hands-on Immersion Day. Events are virtual and hosted at three global time zones. Register here: April 12th.
About the authors:
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/03/security-vulnerabilities-in-snipping-tools.html
Both Google’s Pixel’s Markup Tool and the Windows Snipping Tool have vulnerabilities that allow people to partially recover content that was edited out of images.
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/03/hacks-at-pwn2own-vancouver-2023.html
An impressive array of hacks were demonstrated at the first day of the Pwn2Own conference in Vancouver:
On the first day of Pwn2Own Vancouver 2023, security researchers successfully demoed Tesla Model 3, Windows 11, and macOS zero-day exploits and exploit chains to win $375,000 and a Tesla Model 3.
The first to fall was Adobe Reader in the enterprise applications category after Haboob SA’s Abdul Aziz Hariri (@abdhariri) used an exploit chain targeting a 6-bug logic chain abusing multiple failed patches which escaped the sandbox and bypassed a banned API list on macOS to earn $50,000.
The STAR Labs team (@starlabs_sg) demoed a zero-day exploit chain targeting Microsoft’s SharePoint team collaboration platform that brought them a $100,000 reward and successfully hacked Ubuntu Desktop with a previously known exploit for $15,000.
Synacktiv (@Synacktiv) took home $100,000 and a Tesla Model 3 after successfully executing a TOCTOU (time-of-check to time-of-use) attack against the Tesla-Gateway in the Automotive category. They also used a TOCTOU zero-day vulnerability to escalate privileges on Apple macOS and earned $40,000.
Oracle VirtualBox was hacked using an OOB Read and a stacked-based buffer overflow exploit chain (worth $40,000) by Qrious Security’s Bien Pham (@bienpnn).
Last but not least, Marcin Wiązowski elevated privileges on Windows 11 using an improper input validation zero-day that came with a $30,000 prize.
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/03/friday-squid-blogging-creating-batteries-out-of-squid-cells.html
This is fascinating:
“When a squid ends up chipping what’s called its ring tooth, which is the nail underneath its tentacle, it needs to regrow that tooth very rapidly, otherwise it can’t claw its prey,” he explains.
This was intriguing news and it sparked an idea in Hopkins lab where he’d been trying to figure out how to store and transmit heat.
“It diffuses in all directions. There’s no way to capture the heat and move it the way that you would electricity. It’s just not a fundamental law of physics.”
[…]
The tiny brown batteries he mentions are about the size of a chiclet, and Hopkins says it will take a decade or more to create larger batteries that could have commercial value.
As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.
Read my blog posting guidelines here.
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/03/a-hackers-mind-news-2.html
My latest book continues to sell well. Its ranking hovers between 1,500 and 2,000 on Amazon. It’s been spied in airports.
Reviews are consistently good. I have been enjoying giving podcast interviews. It all feels pretty good right now.
You can order a signed book from me here.
For those of you in New York, I’m giving at book talk at the Ford Foundation on Thursday, April 6. Admission is free, but you have to register.
Post Syndicated from Sheila Busser original https://aws.amazon.com/blogs/compute/building-diversified-and-cost-optimized-ec2-server-groups-in-spinnaker/
This blog post is written by Sandeep Palavalasa, Sr. Specialist Containers SA, and Prathibha Datta-Kumar, Software Development Engineer
Spinnaker is an open source continuous delivery platform created by Netflix for releasing software changes rapidly and reliably. It enables teams to automate deployments into pipelines that are run whenever a new version is released with proven deployment strategies that are faster and more dependable with zero downtime. For many AWS customers, Spinnaker is a critical piece of technology that allows developers to deploy their applications safely and reliably across different AWS managed services.
Listening to customer requests on the Spinnaker open source project and in the Amazon EC2 Spot Instances integrations roadmap, we have further enhanced Spinnaker’s ability to deploy on Amazon Elastic Compute Cloud (Amazon EC2). The enhancements make it easier to combine Spot Instances with On-Demand, Reserved, and Savings Plans Instances to optimize workload costs with performance. You can improve workload availability when using Spot Instances with features such as allocation strategies and proactive Spot capacity rebalancing, when you are flexible about Instance types and Availability Zones. Combinations of these features offer the best possible experience when using Amazon EC2 with Spinnaker.
In this post, we detail the recent enhancements, along with a walkthrough of how you can use them following the best practices.
EC2 Spot Instances are spare compute capacity in the AWS Cloud available at steep discounts of up to 90% when compared to On-Demand Instance prices. The primary difference between an On-Demand Instance and a Spot Instance is that a Spot Instance can be interrupted by Amazon EC2 with a two-minute notification when Amazon EC2 needs the capacity back. Amazon EC2 now sends rebalance recommendation notifications when Spot Instances are at an elevated risk of interruption. This signal can arrive sooner than the two-minute interruption notice. This lets you proactively replace your Spot Instances before it’s interrupted.
The best way to adhere to Spot best practices and instance fleet management is by using an Amazon EC2 Auto Scaling group When using Spot Instances in Auto Scaling group, enabling Capacity Rebalancing helps you maintain workload availability by proactively augmenting your fleet with a new Spot Instance before a running instance is interrupted by Amazon EC2.
Spinnaker uses three key concepts to describe your services, including applications, clusters, and server groups, and how your services are exposed to users is expressed as Load balancers and firewalls.
An application is a collection of clusters, a cluster is a collection of server groups, and a server group identifies the deployable artifact and basic configuration settings such as the number of instances, autoscaling policies, metadata, etc. This corresponds to an Auto Scaling group in AWS. We use Auto Scaling groups and server groups interchangeably in this post.
In mid-2020, we started looking into customer requests and gaps in the Amazon EC2 feature set supported in Spinnaker. Around the same time, Spinnaker OSS added support for Amazon EC2 Launch Templates. Thanks to their effort, we could follow-up and expand the Amazon EC2 feature set supported in Spinnaker. Now that we understand the new features, let’s look at how to use some of them in the following tutorial spinnaker.io.
Here are some highlights of the features contributed recently:
| Feature | Why use it? (Example use cases) |
| Multiple Instance Types | Tap into multiple capacity pools to achieve and maintain the desired scale using Spot Instances. |
| Combining On-Demand and Spot Instances |
– Control the proportion of On-Demand and Spot Instances launched in your sever group. – Combine Spot Instances with Amazon EC2 Reserved Instances or Savings Plans. |
| Amazon EC2 Auto Scaling allocation strategies | Reduce overall Spot interruptions by launching from Spot pools that are optimally chosen based on the available Spot capacity, using capacity-optimized Spot allocation strategy. |
| Capacity rebalancing | Improve your workload availability by proactively shifting your Spot capacity to optimal pools by enabling capacity rebalancing along with capacity-optimized allocation strategy. |
| Improved support for burstable performance instance types with custom credit specification | Reduce costs by preventing wastage of CPU cycles. |
We recommend using Spinnaker stable release 1.28.x for API users and 1.29.x for UI users. Here is the Git issue for related PRs and feature releases.
Now that we understand the new features, let’s look at how to use some of them in the following tutorial.
In this example tutorial, we setup Spinnaker to deploy to Amazon EC2, create an Application Load Balancer, and deploy a demo application on a server group diversified across multiple instance types and purchase options – this case On-Demand and Spot Instances.
We leverage Spinnaker’s API throughout the tutorial to create new resources, along with a quick guide on how to deploy the same using Spinnaker UI (Deck) and leverage UI to view them.
As a prerequisite to complete this tutorial, you must have an AWS Account with an AWS Identity and Access Management (IAM) User that has the AdministratorAccess configured to use with AWS Command Line Interface (AWS CLI).
1. Spinnaker setup
We will use the AWS CloudFormation template setup-spinnaker-with-deployment-vpc.yml to setup Spinnaker and the required resources.
1.1 Create an Secure Shell(SSH) keypair used to connect to Spinnaker and EC2 instances launched by Spinnaker.
AWS_REGION=us-west-2 # Change the region where you want Spinnaker deployed
EC2_KEYPAIR_NAME=spinnaker-blog-${AWS_REGION}
aws ec2 create-key-pair --key-name ${EC2_KEYPAIR_NAME} --region ${AWS_REGION} --query KeyMaterial --output text > ~/${EC2_KEYPAIR_NAME}.pem
chmod 600 ~/${EC2_KEYPAIR_NAME}.pem
1.2 Deploy the Cloudformation stack.
STACK_NAME=spinnaker-blog
SPINNAKER_VERSION=1.29.1 # Change the version if newer versions are available
NUMBER_OF_AZS=3
AVAILABILITY_ZONES=${AWS_REGION}a,${AWS_REGION}b,${AWS_REGION}c
ACCOUNT_ID=$(aws sts get-caller-identity --query "Account" --output text)
S3_BUCKET_NAME=spin-persitent-store-${ACCOUNT_ID}
# Download template
curl -o setup-spinnaker-with-deployment-vpc.yml https://raw.githubusercontent.com/awslabs/ec2-spot-labs/master/ec2-spot-spinnaker/setup-spinnaker-with-deployment-vpc.yml
# deploy stack
aws cloudformation deploy --template-file setup-spinnaker-with-deployment-vpc.yml \
--stack-name ${STACK_NAME} \
--parameter-overrides NumberOfAZs=${NUMBER_OF_AZS} \
AvailabilityZones=${AVAILABILITY_ZONES} \
EC2KeyPairName=${EC2_KEYPAIR_NAME} \
SpinnakerVersion=${SPINNAKER_VERSION} \
SpinnakerS3BucketName=${S3_BUCKET_NAME} \
--capabilities CAPABILITY_NAMED_IAM --region ${AWS_REGION}
1.3 Connecting to Spinnaker
1.3.1 Get the SSH command to port forwarding for Deck – the browser-based UI (9000) and Gate – the API Gateway (8084) to access the Spinnaker UI and API.
SPINNAKER_INSTANCE_DNS_NAME=$(aws cloudformation describe-stacks --stack-name ${STACK_NAME} --region ${AWS_REGION} --query "Stacks[].Outputs[?OutputKey=='SpinnakerInstance'].OutputValue" --output text)
echo 'ssh -A -L 9000:localhost:9000 -L 8084:localhost:8084 -L 8087:localhost:8087 -i ~/'${EC2_KEYPAIR_NAME}' ubuntu@$'{SPINNAKER_INSTANCE_DNS_NAME}''
1.3.2 Open a new terminal and use the SSH command (output from the previous command) to connect to the Spinnaker instance. After you successfully connect to the Spinnaker instance via SSH, access the Spinnaker UI here and API here.
2. Deploy a demo web application
Let’s make sure that we have the environment variables required in the shell before proceeding. If you’re using the same terminal window as before, then you might already have these variables.
STACK_NAME=spinnaker-blog
AWS_REGION=us-west-2 # use the same region as before
EC2_KEYPAIR_NAME=spinnaker-blog-${AWS_REGION}
VPC_ID=$(aws cloudformation describe-stacks --stack-name ${STACK_NAME} --region ${AWS_REGION} --query "Stacks[].Outputs[?OutputKey=='VPCID'].OutputValue" --output text)
2.1 Create a Spinnaker Application
We start by creating an application in Spinnaker, a placeholder for the service that we deploy.
curl 'http://localhost:8084/tasks' \
-H 'Content-Type: application/json;charset=utf-8' \
--data-raw \
'{
"job":[
{
"type":"createApplication",
"application":{
"cloudProviders":"aws",
"instancePort":80,
"name":"demoapp",
"email":"[email protected]",
"providerSettings":{
"aws":{
"useAmiBlockDeviceMappings":true
}
}
}
}
],
"application":"demoapp",
"description":"Create Application: demoapp"
}'
2.2 Create an Application Load Balancer
Let’s create an Application Load Balanacer and a target group for port 80, spanning the three availability zones in our public subnet. We use the Demo-ALB-SecurityGroup for Firewalls to allow public access to the ALB on port 80.
As Spot Instances are interrupted with a two minute warning, you must adjust the Target Group’s deregistration delay to a slightly lower time. Recommended values are 90 seconds or less. This allows time for in-flight requests to complete and gracefully close existing connections before the instance is interrupted.
curl 'http://localhost:8084/tasks' \
-H 'Content-Type: application/json;charset=utf-8' \
--data-binary \
'{
"application":"demoapp",
"description":"Create Load Balancer: demoapp",
"job":[
{
"type":"upsertLoadBalancer",
"name":"demoapp-lb",
"loadBalancerType":"application",
"cloudProvider":"aws",
"credentials":"my-aws-account",
"region":"'"${AWS_REGION}"'",
"vpcId":"'"${VPC_ID}"'",
"subnetType":"public-subnet",
"idleTimeout":60,
"targetGroups":[
{
"name":"demoapp-targetgroup",
"protocol":"HTTP",
"port":80,
"targetType":"instance",
"healthCheckProtocol":"HTTP",
"healthCheckPort":"traffic-port",
"healthCheckPath":"/",
"attributes":{
"deregistrationDelay":90
}
}
],
"regionZones":[
"'"${AWS_REGION}"'a",
"'"${AWS_REGION}"'b",
"'"${AWS_REGION}"'c"
],
"securityGroups":[
"Demo-ALB-SecurityGroup"
],
"listeners":[
{
"protocol":"HTTP",
"port":80,
"defaultActions":[
{
"type":"forward",
"targetGroupName":"demoapp-targetgroup"
}
]
}
]
}
]
}'
2.3 Create a server group
Before creating a server group (Auto Scaling group), here is a brief overview of the features used in the example:
Learn more on spinnaker.io: feature descriptions and use cases and sample API requests.
Let’s create a server group with a desired capacity of 12 instances diversified across current and previous generation instance types, attach the previously created ALB, use Demo-EC2-SecurityGroup for the Firewalls which allows http traffic only from the ALB, use the following bash script for UserData to install httpd, and add instance metadata into the index.html.
2.3.1 Save the userdata bash script into a file user-date.sh.
Note that Spinnaker only support base64 encoded userdata. We use base64 bash command to encode the file contents in the next step.
cat << "EOF" > user-data.sh
#!/bin/bash
yum update -y
yum install httpd -y
echo "<html>
<head>
<title>Demo Application</title>
<style>body {margin-top: 40px; background-color: #Gray;} </style>
</head>
<body>
<h2>You have reached a Demo Application running on</h2>
<ul>
<li>instance-id: <b> `curl http://169.254.169.254/latest/meta-data/instance-id` </b></li>
<li>instance-type: <b> `curl http://169.254.169.254/latest/meta-data/instance-type` </b></li>
<li>instance-life-cycle: <b> `curl http://169.254.169.254/latest/meta-data/instance-life-cycle` </b></li>
<li>availability-zone: <b> `curl http://169.254.169.254/latest/meta-data/placement/availability-zone` </b></li>
</ul>
</body>
</html>" > /var/www/html/index.html
systemctl start httpd
systemctl enable httpd
EOF2.3.2 Create the server group by running the following command. Note we use the KeyPairName that we created as part of the prerequisites.
curl 'http://localhost:8084/tasks' \
-H 'Content-Type: application/json;charset=utf-8' \
-d \
'{
"job":[
{
"type":"createServerGroup",
"cloudProvider":"aws",
"account":"my-aws-account",
"application":"demoapp",
"stack":"",
"credentials":"my-aws-account",
"healthCheckType": "ELB",
"healthCheckGracePeriod":600,
"capacityRebalance": true,
"onDemandBaseCapacity":3,
"onDemandPercentageAboveBaseCapacity":10,
"spotAllocationStrategy":"capacity-optimized",
"setLaunchTemplate":true,
"launchTemplateOverridesForInstanceType":[
{
"instanceType":"m4.large"
},
{
"instanceType":"m5.large"
},
{
"instanceType":"m5a.large"
},
{
"instanceType":"m5ad.large"
},
{
"instanceType":"m5d.large"
},
{
"instanceType":"m5dn.large"
},
{
"instanceType":"m5n.large"
}
],
"capacity":{
"min":6,
"max":21,
"desired":12
},
"subnetType":"private-subnet",
"availabilityZones":{
"'"${AWS_REGION}"'":[
"'"${AWS_REGION}"'a",
"'"${AWS_REGION}"'b",
"'"${AWS_REGION}"'c"
]
},
"keyPair":"'"${EC2_KEYPAIR_NAME}"'",
"securityGroups":[
"Demo-EC2-SecurityGroup"
],
"instanceType":"m5.large",
"virtualizationType":"hvm",
"amiName":"'"$(aws ec2 describe-images --owners amazon --filters "Name=name,Values=amzn2-ami-hvm-2*x86_64-gp2" --query 'reverse(sort_by(Images, &CreationDate))[0].Name' --region ${AWS_REGION} --output text)"'",
"targetGroups":[
"demoapp-targetgroup"
],
"base64UserData":"'"$(base64 user-data.sh)"'",,
"associatePublicIpAddress":false,
"instanceMonitoring":false
}
],
"application":"demoapp",
"description":"Create New server group in cluster demoapp"
}'
Spinnaker creates an Amazon EC2 Launch Template and an ASG with specified parameters and waits until the ALB health check passes before sending traffic to the EC2 Instances.
The server group and launch template that we just created will look like this in Spinnaker UI:
The UI also displays capacity type, such as the purchase option for each instance type in the Instance Information section:
Copy the Application Load Balancer URL by selecting the tree icon in the right top corner of the server group, and access it in a browser. You can refresh multiple times to see that the requests are going to different instances every time.
Congratulations! You successfully deployed the demo application on an Amazon EC2 server group diversified across multiple instance types and purchase options.
Moreover, you can clone, modify, disable, and destroy these server groups, as well as use them with Spinnaker pipelines to effectively release new versions of your application.
Check the savings you realized by deploying your demo application on EC2 Spot Instances by going to EC2 console > Spot Requests > Saving Summary.
To avoid incurring any additional charges, clean up the resources created in the tutorial.
Frist, delete the server group, application load balancer and application in Spinnaker.
curl 'http://localhost:8084/tasks' \
-H 'Content-Type: application/json;charset=utf-8' \
--data-raw \
'{
"job":[
{
"reason":"Cleanup",
"asgName":"demoapp-v000",
"moniker":{
"app":"demoapp",
"cluster":"demoapp",
"sequence":0
},
"serverGroupName":"demoapp-v000",
"type":"destroyServerGroup",
"region":"'"${AWS_REGION}"'",
"credentials":"my-aws-account",
"cloudProvider":"aws"
},
{
"cloudProvider":"aws",
"loadBalancerName":"demoapp-lb",
"loadBalancerType":"application",
"regions":[
"'"${AWS_REGION}"'"
],
"credentials":"my-aws-account",
"vpcId":"'"${VPC_ID}"'",
"type":"deleteLoadBalancer"
},
{
"type":"deleteApplication",
"application":{
"name":"demoapp",
"cloudProviders":"aws"
}
}
],
"application":"demoapp",
"description":"Deleting ServerGroup, ALB and Application: demoapp"
}'
Wait for Spinnaker to delete all of the resources before proceeding further. You can confirm this either on the Spinnaker UI or AWS Management Console.
Then delete the Spinnaker infrastructure by running the following command:
aws ec2 delete-key-pair --key-name ${EC2_KEYPAIR_NAME} --region ${AWS_REGION}
rm ~/${EC2_KEYPAIR_NAME}.pem
aws s3api delete-objects \
--bucket ${S3_BUCKET_NAME} \
--delete "$(aws s3api list-object-versions \
--bucket ${S3_BUCKET_NAME} \
--query='{Objects: Versions[].{Key:Key,VersionId:VersionId}}')" #If error occurs, there are no Versions and is OK
aws s3api delete-objects \
--bucket ${S3_BUCKET_NAME} \
--delete "$(aws s3api list-object-versions \
--bucket ${S3_BUCKET_NAME} \
--query='{Objects: DeleteMarkers[].{Key:Key,VersionId:VersionId}}')" #If error occurs, there are no DeleteMarkers and is OK
aws s3 rb s3://${S3_BUCKET_NAME} --force #Delete Bucket
aws cloudformation delete-stack --region ${AWS_REGION} --stack-name ${STACK_NAME}
In this post, we learned about the new Amazon EC2 features recently added to Spinnaker, and how to use them to build diversified and optimized Auto Scaling Groups. We also discussed recommended best practices for EC2 Spot and how they can improve your experience with it.
We would love to hear from you! Tell us about other Continuous Integration/Continuous Delivery (CI/CD) platforms that you want to use with EC2 Spot and/or Auto Scaling Groups by adding an issue on the Spot integrations roadmap.
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/03/exploding-usb-sticks.html
In case you don’t have enough to worry about, people are hiding explosives—actual ones—in USB sticks:
In the port city of Guayaquil, journalist Lenin Artieda of the Ecuavisa private TV station received an envelope containing a pen drive which exploded when he inserted it into a computer, his employer said.
Artieda sustained slight injuries to one hand and his face, said police official Xavier Chango. No one else was hurt.
Chango said the USB drive sent to Artieda could have been loaded with RDX, a military-type explosive.
More:
According to police official Xavier Chango, the flash drive that went off had a 5-volt explosive charge and is thought to have used RDX. Also known as T4, according to the Environmental Protection Agency (PDF), militaries, including the US’s, use RDX, which “can be used alone as a base charge for detonators or mixed with other explosives, such as TNT.” Chango said it comes in capsules measuring about 1 cm, but only half of it was activated in the drive that Artieda plugged in, which likely saved him some harm.
Reminds me of assassination by cell phone.
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/03/mass-ransomware-attack.html
A vulnerability in a popular data transfer tool has resulted in a mass ransomware attack:
TechCrunch has learned of dozens of organizations that used the affected GoAnywhere file transfer software at the time of the ransomware attack, suggesting more victims are likely to come forward.
However, while the number of victims of the mass-hack is widening, the known impact is murky at best.
Since the attack in late January or early February—the exact date is not known—Clop has disclosed less than half of the 130 organizations it claimed to have compromised via GoAnywhere, a system that can be hosted in the cloud or on an organization’s network that allows companies to securely transfer huge sets of data and other large files.
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/03/chatgpt-privacy-flaw.html
OpenAI has disabled ChatGPT’s privacy history, almost certainly because they had a security flaw where users were seeing each others’ histories.
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/03/us-citizen-hacked-by-spyware.html
The New York Times is reporting that a US citizen’s phone was hacked by the Predator spyware.
A U.S. and Greek national who worked on Meta’s security and trust team while based in Greece was placed under a yearlong wiretap by the Greek national intelligence service and hacked with a powerful cyberespionage tool, according to documents obtained by The New York Times and officials with knowledge of the case.
The disclosure is the first known case of an American citizen being targeted in a European Union country by the advanced snooping technology, the use of which has been the subject of a widening scandal in Greece. It demonstrates that the illicit use of spyware is spreading beyond use by authoritarian governments against opposition figures and journalists, and has begun to creep into European democracies, even ensnaring a foreign national working for a major global corporation.
The simultaneous tapping of the target’s phone by the national intelligence service and the way she was hacked indicate that the spy service and whoever implanted the spyware, known as Predator, were working hand in hand.
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/03/friday-squid-blogging-new-species-of-vampire-squid-lives-3000-feet-below-sea-level.html
At least, it seems to be a new species.
As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.
Read my blog posting guidelines here.
Post Syndicated from Sheila Busser original https://aws.amazon.com/blogs/compute/architecting-for-data-residency-with-aws-outposts-rack-and-landing-zone-guardrails/
This blog post was written by Abeer Naffa’, Sr. Solutions Architect, Solutions Builder AWS, David Filiatrault, Principal Security Consultant, AWS and Jared Thompson, Hybrid Edge SA Specialist, AWS.
In this post, we will explore how organizations can use AWS Control Tower landing zone and AWS Organizations custom guardrails to enable compliance with data residency requirements on AWS Outposts rack. We will discuss how custom guardrails can be leveraged to limit the ability to store, process, and access data and remain isolated in specific geographic locations, how they can be used to enforce security and compliance controls, as well as, which prerequisites organizations should consider before implementing these guardrails.
Data residency is a critical consideration for organizations that collect and store sensitive information, such as Personal Identifiable Information (PII), financial, and healthcare data. With the rise of cloud computing and the global nature of the internet, it can be challenging for organizations to make sure that their data is being stored and processed in compliance with local laws and regulations.
One potential solution for addressing data residency challenges with AWS is to use Outposts rack, which allows organizations to run AWS infrastructure on premises and in their own data centers. This lets organizations store and process data in a location of their choosing. An Outpost is seamlessly connected to an AWS Region where it has access to the full suite of AWS services managed from a single plane of glass, the AWS Management Console or the AWS Command Line Interface (AWS CLI). Outposts rack can be configured to utilize landing zone to further adhere to data residency requirements.
The landing zones are a set of tools and best practices that help organizations establish a secure and compliant multi-account structure within a cloud provider. A landing zone can also include Organizations to set policies – guardrails – at the root level, known as Service Control Policies (SCPs) across all member accounts. This can be configured to enforce certain data residency requirements.
When leveraging Outposts rack to meet data residency requirements, it is crucial to have control over the in-scope data movement from the Outposts. This can be accomplished by implementing landing zone best practices and the suggested guardrails. The main focus of this blog post is on the custom policies that restrict data snapshots, prohibit data creation within the Region, and limit data transfer to the Region.
Landing zone best practices and custom guardrails can help when data needs to remain in a specific locality where the Outposts rack is also located. This can be completed by defining and enforcing policies for data storage and usage within the landing zone organization that you set up. The following prerequisites should be considered before implementing the suggested guardrails:
1. AWS Outposts rack
AWS has installed your Outpost and handed off to you. An Outpost may comprise of one or more racks connected together at the site. This means that you can start using AWS services on the Outpost, and you can manage the Outposts rack using the same tools and interfaces that you use in AWS Regions.
2. Landing Zone Accelerator on AWS
We recommend using Landing Zone Accelerator on AWS (LZA) to deploy a landing zone for your organization. Make sure that the accelerator is configured for the appropriate Region and industry. To do this, you must meet the following prerequisites:
Note that LZAs are designed to help organizations quickly set up a secure, compliant multi-account environment. However, it’s not a one-size-fits-all solution, and you must align it with your organization’s specific requirements.
3. Set up the data residency guardrails
Using Organizations, you must make sure that the Outpost is ordered within a workload account in the landing zone.
Figure 1: Landing Zone Accelerator – Outposts workload on AWS high level Architecture
When local regulations require regulated workloads to stay within a specific boundary, or when an AWS Region or AWS Local Zone isn’t available in your jurisdiction, you can still choose to host your regulated workloads on Outposts rack for a consistent cloud experience. When opting for Outposts rack, note that, as part of the shared responsibility model, customers are responsible for attesting to physical security, access controls, and compliance validation regarding the Outposts, as well as, environmental requirements for the facility, networking, and power. Utilizing Outposts rack requires that you procure and manage the data center within the city, state, province, or country boundary for your applications’ regulated components, as required by local regulations.
Procuring two or more racks in the diverse data centers can help with the high availability for your workloads. This is because it provides redundancy in case of a single rack or server failure. Additionally, having redundant network paths between Outposts rack and the parent Region can help make sure that your application remains connected and continue to operate even if one network path fails.
However, for regulated workloads with strict service level agreements (SLA), you may choose to spread Outposts racks across two or more isolated data centers within regulated boundaries. This helps make sure that your data remains within the designated geographical location and meets local data residency requirements.
In this post, we consider a scenario with one data center, but consider the specific requirements of your workloads and the regulations that apply to determine the most appropriate high availability configurations for your case.
Organizations provide central governance and management for multiple accounts. Central security administrators use SCPs with Organizations to establish controls to which all AWS Identity and Access Management (IAM) principals (users and roles) adhere.
Now, you can use SCPs to set permission guardrails. A suggested preventative controls for data residency on Outposts rack that leverage the implementation of SCPs are shown as follows. SCPs enable you to set permission guardrails by defining the maximum available permissions for IAM entities in an account. If an SCP denies an action for an account, then none of the entities in the account can take that action, even if their IAM permissions let them. The guardrails set in SCPs apply to all IAM entities in the account, which include all users, roles, and the account root user.
Upon finalizing these prerequisites, you can create the guardrails for the Outposts Organization Unit (OU).
| Note that while the following guidelines serve as helpful guardrails – SCPs – for data residency, you should consult internally with legal and security teams for specific organizational requirements. |
To exercise better control over workloads in the Outposts rack and prevent data transfer from Outposts to the Region or data storage outside the Outposts, consider implementing the following guardrails. Additionally, local regulations may dictate that you set up these additional guardrails.
a. Deny copying data from Outposts to the Region for Amazon Elastic Compute Cloud (Amazon EC2), Amazon Relational Database Service (Amazon RDS), Amazon ElastiCache and data sync “DenyCopyToRegion”.
b. Deny Amazon Simple Storage Service (Amazon S3) put action to the Region “DenyPutObjectToRegionalBuckets”.
|
If your data residency requirements mandate restrictions on data storage in the Region, consider implementing this guardrail to prevent the use of S3 in the Region. Note: You can use Amazon S3 for Outposts. |
c. If your data residency requirements mandate restrictions on data storage in the Region, consider implementing “DenyDirectTransferToRegion” guardrail.
|
Out of Scope is metadata such as tags, or operational data such as KMS keys. |
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyCopyToRegion",
"Action": [
"ec2:ModifyImageAttribute",
"ec2:CopyImage",
"ec2:CreateImage",
"ec2:CreateInstanceExportTask",
"ec2:ExportImage",
"ec2:ImportImage",
"ec2:ImportInstance",
"ec2:ImportSnapshot",
"ec2:ImportVolume",
"rds:CreateDBSnapshot",
"rds:CreateDBClusterSnapshot",
"rds:ModifyDBSnapshotAttribute",
"elasticache:CreateSnapshot",
"elasticache:CopySnapshot",
"datasync:Create*",
"datasync:Update*"
],
"Resource": "*",
"Effect": "Deny"
},
{
"Sid": "DenyDirectTransferToRegion",
"Action": [
"dynamodb:PutItem",
"dynamodb:CreateTable",
"ec2:CreateTrafficMirrorTarget",
"ec2:CreateTrafficMirrorSession",
"rds:CreateGlobalCluster",
"es:Create*",
"elasticfilesystem:C*",
"elasticfilesystem:Put*",
"storagegateway:Create*",
"neptune-db:connect",
"glue:CreateDevEndpoint",
"glue:UpdateDevEndpoint",
"datapipeline:CreatePipeline",
"datapipeline:PutPipelineDefinition",
"sagemaker:CreateAutoMLJob",
"sagemaker:CreateData*",
"sagemaker:CreateCode*",
"sagemaker:CreateEndpoint",
"sagemaker:CreateDomain",
"sagemaker:CreateEdgePackagingJob",
"sagemaker:CreateNotebookInstance",
"sagemaker:CreateProcessingJob",
"sagemaker:CreateModel*",
"sagemaker:CreateTra*",
"sagemaker:Update*",
"redshift:CreateCluster*",
"ses:Send*",
"ses:Create*",
"sqs:Create*",
"sqs:Send*",
"mq:Create*",
"cloudfront:Create*",
"cloudfront:Update*",
"ecr:Put*",
"ecr:Create*",
"ecr:Upload*",
"ram:AcceptResourceShareInvitation"
],
"Resource": "*",
"Effect": "Deny"
},
{
"Sid": "DenyPutObjectToRegionalBuckets",
"Action": [
"s3:PutObject"
],
"Resource": ["arn:aws:s3:::*"],
"Effect": "Deny"
}
]
}
a. Deny creating snapshots of your Outpost data in the Region “DenySnapshotsToRegion”
Make sure to update the Outposts “<outpost_arn_pattern>”.
b. Deny copying or modifying Outposts Snapshots “DenySnapshotsNotOutposts”
Make sure to update the Outposts “<outpost_arn_pattern>”.
Note: “<outpost_arn_pattern>” default is arn:aws:outposts:*:*:outpost/*
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenySnapshotsToRegion",
"Effect":"Deny",
"Action":[
"ec2:CreateSnapshot",
"ec2:CreateSnapshots"
],
"Resource":"arn:aws:ec2:*::snapshot/*",
"Condition":{
"ArnLike":{
"ec2:SourceOutpostArn":"<outpost_arn_pattern>"
},
"Null":{
"ec2:OutpostArn":"true"
}
}
},
{
"Sid": "DenySnapshotsNotOutposts",
"Effect":"Deny",
"Action":[
"ec2:CopySnapshot",
"ec2:ModifySnapshotAttribute"
],
"Resource":"arn:aws:ec2:*::snapshot/*",
"Condition":{
"ArnLike":{
"ec2:OutpostArn":"<outpost_arn_pattern>"
}
}
}
]
}
Make sure to update the Outposts subnets “<outpost_subnet_arns>”.
{
"Version": "2012-10-17",
"Statement":[{
"Sid": "DenyNotOutpostSubnet",
"Effect":"Deny",
"Action": [
"ec2:RunInstances",
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
],
"Condition": {
"ForAllValues:ArnNotEquals": {
"ec2:Subnet": ["<outpost_subnet_arns>"]
}
}
}]
}When implementing data residency guardrails on Outposts rack, consider backup and disaster recovery strategies to make sure that your data is protected in the event of an outage or other unexpected events. This may include creating regular backups of your data, implementing disaster recovery plans and procedures, and using redundancy and failover systems to minimize the impact of any potential disruptions. Additionally, you should make sure that your backup and disaster recovery systems are compliant with any relevant data residency regulations and requirements. You should also test your backup and disaster recovery systems regularly to make sure that they are functioning as intended.
Additionally, the provided SCPs for Outposts rack in the above example do not block the “logs:PutLogEvents”. Therefore, even if you implemented data residency guardrails on Outpost, the application may log data to CloudWatch logs in the Region.
|
Highlights By default, application-level logs on Outposts rack are not automatically sent to Amazon CloudWatch Logs in the Region. You can configure CloudWatch logs agent on Outposts rack to collect and send your application-level logs to CloudWatch logs. logs: PutLogEvents does transmit data to the Region, but it is not blocked by the provided SCPs, as it’s expected that most use cases will still want to be able to use this logging API. However, if blocking is desired, then add the action to the first recommended guardrail. If you want specific roles to be allowed, then combine with the ArnNotLike condition example referenced in the previous highlight. |
The combined use of Outposts rack and the suggested guardrails via AWS Organizations policies enables you to exercise better control over the movement of the data. By creating a landing zone for your organization, you can apply SCPs to your Outposts racks that will help make sure that your data remains within a specific geographic location, as required by the data residency regulations.
Note that, while custom guardrails can help you manage data residency on Outposts rack, it’s critical to thoroughly review your policies, procedures, and configurations to make sure that they are compliant with all relevant data residency regulations and requirements. Regularly testing and monitoring your systems can help make sure that your data is protected and your organization stays compliant.
Post Syndicated from Anna Brinkmann original https://aws.amazon.com/blogs/security/new-aws-security-blog-homepage/
We’ve launched a new AWS Security Blog homepage! While we currently have no plans to deprecate our existing list-view homepage, we have recently launched a new, security-centered homepage to provide readers with more blog info and easy access to the rest of AWS Security. Please bookmark the new page, and let us know what you think, by adding a comment, below.
The new AWS Security Blog homepage
If you have feedback about this post, submit comments in the Comments section below.
Want more AWS Security news? Follow us on Twitter.
Post Syndicated from VassilKendov original http://kendov.com/bank-crises/
Пиша тази статия поради многото запитвания на познати как да постъпят в конкретната ситуация с личните си финанси. Не мога да отделя на всички време по телефона, затова ще обясня на разбираем език какво се случва с банките, а по-надолу ще публикувам форма със заявка, за тези които искат да направим конкретна среща и да получат съвет или мнение, съобразени с техните лични финансови намерения.
За да разберем проблема и как ще ни засегне е нужно да познаваме малко от малко основните макроикономически принципи и как работи финансовата система.
Буквално в няколко реда ще обясня на достъпен език, някои от основните пазарни принципи, имащи отношение към сегашната ситуация.
Няй-силният лост за управлението на една икономика е ПАРИЧНАТА МАСА В ОБРАЩЕНИЕ! Тоест парите с които ние боравим. Трябва да знаете, че няма по-силен лост за влияние върху икономиката от този. Когато се развиваш и растеш, печаташ пари за да обслужиш или инициираш този ръст. Когато се появи инфлация от многото пазаруване, вдигаш лихвите за да вкараш парите в банките (на депозити или в ценни книги) и те да не участват в оборота. По този начин също така вдигаш стойността на парите и тушираш инфлацията.
За актуални финансови новини можете да използвате Telegram канала Kendov.com
Когато банките имат излишни пари и достатъчно депозити, с част от тях те купуват ценни книги. Много често това са държавни облигации. Тук ключовия момент е „ЧАСТ ОТ ТЯХ”. Никоя банка няма да допусне портфейла и да се състои само и единствено от ДЦК (държавни ценни книжа). Счита се че ДЦК са безрискови, понеже държавата не може да фалира. Най-малкото може винаги да напечата пари и да покрие задълженията си с цената на инфлация. Затова и инфлацията често се използва за „ликвидиране” на задълженията. Помните голямата инфлация в България през 90-те, когато с доживотните си спестявания си купихте един чифт дънки или обратното – когато с една заплата си погасихте жилищния кредит за следващите 15 години?
Това е един много опростен модел, но трябва да го споменем, за да сме сигурни, че ще разберем важността на случващото се в момента и връзката му с нашите лични финанси.
Какво се случи на практика
От 2008 година насам, централните банки по света пуснаха в обращение БЕЗПРЕЦЕДЕНТНО количество пари. Някой дори заговориха за „хеликоптерни пари”, но сега няма да се отклонявам за да обяснявам какво е това (в Гугъл има достатъчно информация).
На тази графика Федералния резерв на САЩ са дали как се движи през годините паричната маса в обращение М1 (парите в обращение + кредитните карти+краткосрочните депозити).
От кризата през 2008 виждате, че тази маса нараства. През 2020 има една промяна в начина на отчитане и затова графиката изглежда така. Но като цяло виждате, че преди САЩ да започнат да вдигат лихвите 2021-ва, паричната маса в обращение расте. И то расте добре. Мисля, че няма смисъл да се чудим откъде дойде инфлацията. Само да отбележа, че у нас дойде главно през валутния борд и свързаноста на лева с еврото. Тоест дойде от инфлацията в ЕС, където от 2008 насам също се пуснаха в обращение безпрецедентно количество пари.
През всичките тези годни ливите бяха на исторически ниски нива. EURIBOR-a дори беше отрицателен. Имаше момент в който Германия пусна ДЦК с отрицателна доходност и те бяха изкупени. Тоест като ги купуваш си наясно, че ще си на загуба, но го правиш. Не ме питайте защо, и аз не знам но го правеха.
Като резултат банките се „набълбукаха” с такива дългосрочни и бездоходни ДЦК, но лихвите започнаха да се качват. Както в САЩ, така и в Европа. Този четвъртък ЕЦБ дори вдигна лихвата с още 0.5%.
По този начин купените вече ДЦК започват да губят стойност, защото новите са с 3-4% доходност, а старите с 0-0,5% доходност и то ако ги държиш до падежа. Но пък са част от активите на банката, за съжаление вече с по-ниска цена, защото никой не иска да ги купи. Тоест би ги купил с голяма отстъпка и това вече е загуба за банката.
За срещa моля използвайте посочената форма.
[contact-form-7]
За вида и качеството на активите има изисквания от страна на централните банки и точно в този момент те поискаха от търговските банки да направят преоценка на активите си, по новите пазарни цени.
Както сами се сещате, това доведе до отчитане на загуби и изисквания тези активи да бъдат заменени с други по-стойностни, за които се изискваше събиране на капитал от фондовите борси.
Това добре, но вие бихте ли си купили облигации или акции на губещо предприятие, защото след преоценката банките вече бяха на загуба?
Това комбинирано с действията на директорите на банките, които побързаха да продадат акциите си и да изтеглят депозитите си, доведе до така наречения “bank run” – всички теглят авоарите си от тази банка и продават ценните си книги.
Същото става и в Европа, но по традиция малко закъснение.
Горните са фактите, но интерпретацията им е важна за да сформирате очакванията си.
Доколкото сме в пазарна икономика, фалита би следвало да е нещо нормално. Виждаме обаче, че някои не е приемливо да фалират и затова им помагаме. На други обаче не.
В случая със SVB Bank, Федералния резерв на САЩ взе решение да гарантира депозитите без значение от размера им, защото това са парите на IТ компаниите. Как става това? С пускане на пазара на още пари.
Днес обявиха, че ще бъде спасена и другата закъсала регионална банка – First Republic. Тя щяла да бъде спасена чрез предоставянето на депозити от големите банки, членове на федералния резерв на САЩ.
За Credit Siusse вече знаете, че също ще бъде спасена с помощ от централната банка на Швейцария в размер на 50 млрд франка. Смятайте го като инжектиране на още 50 млрд в обращение. И инфлацията е гарантирана!
Без значение как ще бъдат спасени банките, това ще доведе до увеличение на паричната маса в обращение и то във времена на достатъчно голяма инфлация (около 9.2% средно за ЕС). Но и това не е най-голямият проблем.
Спасявайки големите банки, се случват няколко социални феномена
– Вече не е пазарно да фалираш! Влизаме в комунизма, където предприятията работеха на загуба и накрая държавата покриваше загубата. В сегашния социален строй обаче, загубите в крайна сметка ще се покрият от хората. А какво друго е инфлацията?
10% инфлация си е близо 10% спад в доходите или 10% данък. Разглеждайте го както ви харесва, но в крайна сметка плащат хората.
– Как очакваме малките да пораснат, ако всеки път спасяваме неефективните големи, за сметка на малките по-прогресивни? Представете си как това влияе на мотивацията на бизнеса. Посланието е – „Колкото и да работиш, голям няма да станеш ако не ти позволим.”
Най-големия проблем от финансова гледна точка е поставянето в подчинение на получилите помощ финансови институции. Разбрате, че няма как просто да им дадат парите, без да има условия. Но всяко условие си е вид подчинение.
Интересно ми е дали и други банки биха „симулирали” фалит за да получат и те помощи.
Наивно е да си мислим, че централните банки не са знаели какво ще се случи, ако вдигнат лихвите и накарат търговските банки да преоценят активите си. Те много добре знаят какъв е портфейла на всяка подотчетна банка и как би повлияло това.
Въпросът е защо го направиха и защо сега?
Лично моето очакване е за още по-висока инфлация и лихви, което да доведе до условия за въвеждане на CBDCs – дигитални пари. Но това е друга тема и за последствията от тяхното въвеждане тепърва ще четете, а аз тепърва ще пиша.
През това време е редно всеки да помисли за спестяванията си и въобще за личните си финанси. Ще помогна с каквото мога, но всеки сам трябва да вземе решение какво да прави в тези условия. В тази ситуация няма после. После е инфлацията!
Ако статията Ви е харесала, помогнете да развием този блог като го споделите на стената си във ФБ. Благодаря Ви предварително.
Можете да се включите в дискусията в Telegram канала Kendov.com
За контакт
[contact-form-7]
The post Какво се случва с банките в момента, преведено на достъпен език appeared first on Kendov.com.
By continuing to use the site, you agree to the use of cookies. more information
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.