Go 1.20 released

Post Syndicated from original https://lwn.net/Articles/921894/

Version 1.20 of the Go language
has been released.

We’re particularly excited to launch a preview of profile-guided
optimization (PGO), which enables the compiler to perform
application- and workload-specific optimizations based on run-time
profile information. Providing a profile to go build enables the
compiler to speed up typical applications by around 3–4%, and we
expect future releases to benefit even more from PGO. Since this is
a preview release of PGO support, we encourage folks to try it out,
but there are still rough edges which may preclude production use.

Go 1.20 also includes a handful of language changes, many
improvements to tooling and the library, and better overall
performance.

[$] Convergence in the pip and conda worlds?

Post Syndicated from original https://lwn.net/Articles/921097/

The discussions about the world of Python packaging and the
problems caused by its disparate tools and incompatible ecosystems are
still ongoing. Last week, we looked at the
beginnings of the conversation in mid-November, as the discussion
turned toward a possible convergence between two of the major
package-management players: pip and conda. There are numerous
barriers to bringing the two closer together, inertia not least, but the
advantages for users of both, as well as new users to come, could be
substantial.

XDR, the Beatles, and Blunt Instruments

Post Syndicated from Amy Hunt original https://blog.rapid7.com/2023/02/01/xdr-the-beatles-and-blunt-instruments/

XDR, the Beatles, and Blunt Instruments

Sometimes tools are blunt because there’s nothing else. Regarding economic controls for example, Fed Chair Jerome Powell said: “We have essentially interest rates, the balance sheet and forward guidance. They are famously blunt tools, they are not capable of surgical precision.”

Others are blunt because they’re new and these things take time. For example: stereos in the 1960s shook the floors with unrestrained subwoofers. Yes, it was the Beatles and Ringo Star on the drums, but still. It took years to refine this new technology to enhance the music instead of assaulting our senses.

Taking off shoes at the airport? Blunt.

Years later, Real ID and TSA Pre-Check®? Better.

Coming soon: Facial recognition and biometric screening, better still—after privacy concerns are addressed.  

Cybersecurity has used blunt tools, followed by far too many “better ones.” The average security team is now managing 76 tools, and spending more than half their time manually producing reports. The way out is a sharp tool to replace all these better ones—a resource that will actually get the job done. Start with our newly released 2023 XDR Buyer’s Guide.

XDR consolidation and precision has arrived, just know what to look for

Security programs succeed when they have a library of curated, high-fidelity detections backed by threat intelligence that they can trust out-of-the-box. Anything else is low performance guesswork.

Huge numbers of alerts that teams must review and triage can lead to missing high profile threats. Extended Detection and Response (XDR) solutions deliver tailored security alerts that are quantified and scored to improve signal-to-noise ratio and help catch threats early in the attack chain. XDR also eliminates context switching and ensures you have high context, correlated investigation details, blending relevant data from across different event sources into one, coherent picture.

XDR delivered: MDR

With Rapid7, XDR security can also be delivered to you as an end-to-end, turnkey service. Managed detection and response (MDR) can be a game changer, with always-on threat detection, incident validation, and response (such as threat containment). Some providers offer features like threat intelligence, human-led threat hunting, behavior analytics, automation, and more to your capabilities.

A good MDR provider will be 100% end-to-end responsible, however, it should also be an extension of your in-house team. Look for a provider that will freely share the XDR technology with your in-house operation, and work transparently. Your team should be able to observe your environment exactly as the MDR team does, do their own threat hunting, and more—whatever level of collaboration you’d like to see.

2023 is the year of consolidation and XDR. But no change, however awesome or overdue, is easy. We hope this XDR Buyer’s Guide helps.

XDR, the Beatles, and Blunt Instruments

C can be memory-safe

Post Syndicated from original https://blog.erratasec.com/2023/02/c-can-be-memory-safe.html

The idea of memory-safe languages is in the news lately. C/C++ is famous for being the world’s system language (that runs most things) but also infamous for being unsafe. Many want to solve this by hard-forking the world’s system code, either by changing C/C++ into something that’s memory-safe, or rewriting everything in Rust.

Forking is a foolish idea. The core principle of computer-science is that we need to live with legacy, not abandon it.

And there’s no need. Modern C compilers already have the ability to be memory-safe, we just need to make minor — and compatible — changes to turn it on. Instead of a hard-fork that abandons legacy system, this would be a soft-fork that enables memory-safety for new systems.

Consider the most recent memory-safety flaw in OpenSSL. They fixed it by first adding a memory-bounds, then putting every access to the memory behind a macro PUSHC() that checks the memory-bounds:

A better (but currently hypothetical) fix would be something like the following:

size_t maxsize CHK_SIZE(outptr) = out ? *outlen : 0;
This would link the memory-bounds maxsize with the memory outptr. The compiler can then be relied upon to do all the bounds checking to prevent buffer overflows, the rest of the code wouldn’t need to be changed.
An even better (and hypothetical) fix would be to change the function declaration like the following:
int ossl_a2ulabel(const char *in, char *out, size_t *outlen CHK_INOUT_SIZE(out));
That’s the intent anyway, that *outlen is the memory-bounds of out on input, and receives a shorter bounds on output.
This specific feature isn’t in compilers. But gcc and clang already have other similar features. They’ve only been halfway implemented. This feature would be relatively easy to add. I’m currently studying the code to see how I can add it myself. I could just mostly copy what’s done for the alloc_size attribute. But there’s a considerable learning curve, I’d rather just persuade an existing developer of gcc or clang to add the new attributes for me.
Once you give the programmer the ability to fix memory-safety problems like the solution above, you can then enable warnings for unsafe code. The compiler knew the above code was unsafe, but since there’s no practical way to fix it, it’s pointless nagging the programmer about it. With this new features comes warnings about failing to use it.
In other words, it becomes compiler-guided refactoring. Forking code is hard, refactoring is easy.
As the above function shows, the OpenSSL code is already somewhat memory safe, just based upon the flawed principle of relying upon diligent programmers. We need the compiler to enforce it. With such features, the gap is relative small, mostly just changing function parameter lists and data structures to link a pointer with its memory-bounds. The refactoring effort would be small, rather than a major rewrite.
This would be a soft-fork. The memory-bounds would work only when compiled with new compilers. The macro would be ignored on older systems. 
This memory-safety is a problem. The idea of abandoning C/C++ isn’t a solution. We already have the beginnings of a solution in modern gcc and clang compilers. We just need to extend that solution.

Amazon EMR launches support for Amazon EC2 C7g (Graviton3) instances to improve cost performance for Spark workloads by 7–13%

Post Syndicated from Al MS original https://aws.amazon.com/blogs/big-data/amazon-emr-launches-support-for-amazon-ec2-c7g-graviton3-instances-to-improve-cost-performance-for-spark-workloads-by-7-13/

Amazon EMR provides a managed service to easily run analytics applications using open-source frameworks such as Apache Spark, Hive, Presto, Trino, HBase, and Flink. The Amazon EMR runtime for Spark and Presto includes optimizations that provide over twice the performance improvements compared to open-source Apache Spark and Presto.

With Amazon EMR release 6.7, you can now use Amazon Elastic Compute Cloud (Amazon EC2) C7g instances, which use the AWS Graviton3 processors. These instances improve price-performance of running Spark workloads on Amazon EMR by 7.93–13.35% over previous generation instances, depending on the instance size. In this post, we describe how we estimated the price-performance benefit.

Amazon EMR runtime performance with EC2 C7g instances

We ran TPC-DS 3 TB benchmark queries on Amazon EMR 6.9 using the Amazon EMR runtime for Apache Spark (compatible with Apache Spark 3.3) with C7g instances. Data was stored in Amazon Simple Storage Service (Amazon S3), and results were compared to equivalent C6g clusters from the previous generation instance family. We measured performance improvements using the total query runtime and geometric mean of the query runtime across TPC-DS 3 TB benchmark queries.

Our results showed 13.65–18.73% improvement in total query runtime performance and 16.98–20.28% improvement in geometric mean on EMR clusters with C7g compared to equivalent EMR clusters with C6g instances, depending on the instance size. In comparing costs, we observed 7.93–13.35% reduction in cost on the EMR cluster with C7g compared to the equivalent with C6g, depending on the instance size. We did not benchmark the C6g xlarge instance because it didn’t have sufficient memory to run the queries.

The following table shows the results from running the TPC-DS 3 TB benchmark queries using Amazon EMR 6.9 compared to equivalent C7g and C6g instance EMR clusters.

Instance Size 16 XL 12 XL 8 XL 4 XL 2 XL
Total size of the cluster (1 leader + 5 core nodes) 6 6 6 6 6
Total query runtime on C6g (seconds) 2774.86205 2752.84429 3173.08086 5108.45489 8697.08117
Total query runtime on C7g (seconds) 2396.22799 2336.28224 2698.72928 4151.85869 7249.58148
Total query runtime improvement with C7g 13.65% 15.13% 14.95% 18.73% 16.64%
Geometric mean query runtime C6g (seconds) 22.2113 21.75459 23.38081 31.97192 45.41656
Geometric mean query runtime C7g (seconds) 18.43905 17.65898 19.01684 25.48695 37.43737
Geometric mean query runtime improvement with C7g 16.98% 18.83% 18.66% 20.28% 17.57%
EC2 C6g instance price ($ per hour) $2.1760 $1.6320 $1.0880 $0.5440 $0.2720
EMR C6g instance price ($ per hour) $0.5440 $0.4080 $0.2720 $0.1360 $0.0680
(EC2 + EMR) instance price ($ per hour) $2.7200 $2.0400 $1.3600 $0.6800 $0.3400
Cost of running on C6g ($ per instance) $2.09656 $1.55995 $1.19872 $0.96493 $0.82139
EC2 C7g instance price ($ per hour) $2.3200 $1.7400 $1.1600 $0.5800 $0.2900
EMR C7g price ($ per hour per instance) $0.5800 $0.4350 $0.2900 $0.1450 $0.0725
(EC2 + EMR) C7g instance price ($ per hour) $2.9000 $2.1750 $1.4500 $0.7250 $0.3625
Cost of running on C7g ($ per instance) $1.930290 $1.411500 $1.086990 $0.836140 $0.729990
Total cost reduction with C7g including performance improvement -7.93% -9.52% -9.32% -13.35% -11.13%

The following graph shows per-query improvements observed on C7g 2xlarge instances compared to equivalent C6g generations.

Benchmarking methodology

The benchmark used in this post is derived from the industry-standard TPC-DS benchmark, and uses queries from the Spark SQL Performance Tests GitHub repo with the following fixes applied.

We calculated TCO by multiplying cost per hour by number of instances in the cluster and time taken to run the queries on the cluster. We used on-demand pricing in the US East (N. Virginia) Region for all instances.

Conclusion

In this post, we described how we estimated the cost-performance benefit from using Amazon EMR with C7g instances compared to using equivalent previous generation instances. Using these new instances with Amazon EMR improves cost-performance by an additional 7–13%.

About the authors

AI MSAl MS is a product manager for Amazon EMR at Amazon Web Services.

Kyeonghyun Ryoo is a Software Development Engineer for EMR at Amazon Web Services. He primarily works on designing and building automation tools for internal teams and customers to maximize their productivity. Outside of work, he is a retired world champion in professional gaming who still enjoy playing video games.

Yuzhou Sun is a software development engineer for EMR at Amazon Web Services.

Steve Koonce is an Engineering Manager for EMR at Amazon Web Services.

TrenchBoot Anti Evil Maid for Qubes OS

Post Syndicated from original https://lwn.net/Articles/921870/

The Qubes OS news site has a
detailed article on work being done to ensure the integrity of the
system at boot time.

As you may know, traditional firmware security measures like UEFI
Secure Boot and measured boot, even with a Static Root of Trust
(SRT), may only sometimes be enough to ensure a completely secure
environment for your operating system. Compromised firmware may
allow for the injection of malicious software into your system,
making it difficult to detect. To overcome these limitations, many
silicon vendors have started implementing Dynamic Root of Trust
(DRT) technologies to establish a secure environment for operating
system launch and integrity measurements. We’re excited to take
advantage of these advancements through integration with the
TrenchBoot Project.

GitHub Availability Report: January 2023

Post Syndicated from Jakub Oleksy original https://github.blog/2023-02-01-github-availability-report-january-2023/

In January, we experienced two incidents. One that resulted in degraded performance for GitHub Packages and GitHub Pages, and another that impacted git users.

January 30 21:48 UTC (lasting 35 minutes)

Our service monitors detected degraded performance for GitHub Packages and GitHub Pages. Most requests to the container registry were failing and some GitHub Pages builds were also impacted. We determined this was caused by a backend change and mitigated by reverting that change.

Due to the recency of this incident, we are still investigating the contributing factors and will provide a more detailed update in next month’s report.

January 30 18:35 UTC (lasting 7 hours)

We upgraded our production Git binary with a recent version from upstream. The updates included a change to use an internal implementation of gzip when generating archives. This resulted in subtle changes to the contents of the “Download Source” links served by GitHub, leading to checksum mismatches. No content was changed.

After becoming aware of the impact to many communities, we rolled back the compression change to restore the previous behavior.

Similar to the above, we are still investigating the contributing factors of this incident, and will provide a more thorough update in next month’s report.

Please follow our status page for real-time updates on status changes. To learn more about what we’re working on, check out the GitHub Engineering Blog.

CVE-2023-22374: F5 BIG-IP Format String Vulnerability

Post Syndicated from Ron Bowes original https://blog.rapid7.com/2023/02/01/cve-2023-22374-f5-big-ip-format-string-vulnerability/

CVE-2023-22374: F5 BIG-IP Format String Vulnerability

While following up our previous work on F5’s BIG-IP devices, Rapid7 found an additional vulnerability in the appliance-mode REST interface; the vulnerability was assigned CVE-2023-22374. We reported it to F5 on December 6, 2022, and are now disclosing it in accordance with our vulnerability disclosure policy.
The specific issue we discovered is an authenticated format string vulnerability (CWE-134) in the SOAP interface (iControlPortal.cgi), which runs as root and requires an administrative login to access. By inserting format string specifiers (such as %s or %n) into certain GET parameters, an attacker can cause the service to read and write memory addresses that are referenced from the stack. In addition to being an authenticated administrative endpoint, the disclosed memory is written to a log (making it a blind attack). It is difficult to influence the specific addresses read and written, which makes this vulnerability very difficult to exploit (beyond crashing the service) in practice. This has a CVSS score of 7.5 for standard mode deployments and 8.5 in appliance mode.

Products

This issue affects BIG-IP only (not BIG-IQ), and as of writing are not yet patched. The currently supported versions known to be vulnerable are:

  • F5 BIG-IP 17.0.0
  • F5 BIG-IP 16.1.2.2 – 16.1.3
  • F5 BIG-IP 15.1.5.1 – 15.1.8
  • F5 BIG-IP 14.1.4.6 – 14.1.5
  • F5 BIG-IP 13.1.5

Discoverer

This issue was discovered by Ron Bowes of Rapid7. It is being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

Exploitation

The issue we are disclosing is a blind format string vulnerability, where an authenticated attacker can insert arbitrary format string characters (such as %d, %x, %s, and %n) into a query parameter, which are passed into the function syslog(), which processes format-string specifiers. This does not require the attacker to actually read the syslog entries—it’s the act of parsing the format string that is problematic. That also means that the attacker can’t read the memory, unless they have an additional way to read the syslog. By using the %s specifier, the service can be trivially crashed with a segmentation fault (because it tries to dereference pointers on the stack as strings). Using %n, arbitrary data can be written to any pointer found on the stack—depending on what’s present on the stack, this may be exploitable for remote code execution.

The issue occurs in WSDL= parameter in the following authenticated administrative URL:

The value of the WSDL= parameter is written to the syslog:

Nov 29 08:32:25 bigip.example.org soap[4335]: query: WSDL=ASM.LoggingProfile

If an attacker adds format-string characters to that argument, they will be processed and values from the stack can be written to the syslog (an attacker wouldn’t be able to see this, so it’s actually a blind format-string vulnerability). For example, this URL:

  • https://bigip.example.com/iControl/iControlPortal.cgi?WSDL=ASM.LoggingProfile:%08x:%08x:%08x:%08x:%08x:%08x:%08x:%08x

Might write the following, after expanding the %08x format specifiers to values from the stack (the colons are just for readability):

Nov 29 08:41:47 bigip.example.org soap[4335]: query: WSDL=ASM.LoggingProfile:0000004c:0000004c:08cb31bc:08cba210:08cc4954:01000000:ffeaa378:f5aa8000

Once again, we should note that an attacker cannot see this log, and therefore cannot use this to disclose memory. We can, however, use a %s format specifier to tell the service to try and render a string from the stack. If the value on the stack is not a valid memory address (such as the first value, which is 0x0000004c), the process will crash with a segmentation fault. We can also use the %n format specifier to write a (mostly) arbitrary value to a memory address found on the stack.

Here is an example of using the %s specifier in a request:

  • https://bigip.example.com/iControl/iControlPortal.cgi?WSDL=ASM.LoggingProfile:%s

If we send that to the server (as an authenticated request), the service will crash. We can attach a debugger to the server process to validate:

[root@bigip:Active:Standalone] config # /tmp/gdb-7.10.1-x64 -q --pid=4335[...](gdb) contContinuing.
Program received signal SIGSEGV, Segmentation fault.0xf55e3085 in vfprintf () from /lib/libc.so.6(gdb) bt#0  0xf55e3085 in vfprintf () from /lib/libc.so.6#1  0xf568f21f in __vsyslog_chk () from /lib/libc.so.6#2  0xf568f317 in syslog () from /lib/libc.so.6#3  0x0810cc1f in PortalDispatch::HandleWSDLRequest(char*) ()#4  0x08109f08 in iControlPortal::run(int) ()#5  0x0810947f in main ()

The actual vulnerable code in PortalDispatch::HandleWSDLRequest in iControlPortal.cgi is (in a disassembler):

.text:0810CBF2 loc_810CBF2:                            ; CODE XREF: PortalDispatch::HandleWSDLRequest(char *)+DD↑j.text:0810CBF2                 pop     ecx.text:0810CBF3                 pop     edi.text:0810CBF4                 push    esi             ; Query string.text:0810CBF5                 push    eax.text:0810CBF6                 call    __ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc ; std::operator<<<std::char_traits<char>>(std::basic_ostream<char,std::char_traits<char>> &,char const*).text:0810CBFB                 pop     eax.text:0810CBFC                 pop     edx.text:0810CBFD                 lea     eax, [ebp+var_8C8].text:0810CC03                 lea     edi, [ebp+format].text:0810CC09                 push    eax.text:0810CC0A                 push    edi.text:0810CC0B                 call    __ZNKSt15basic_stringbufIcSt11char_traitsIcESaIcEE3strEv ; std::basic_stringbuf<char,std::char_traits<char>,std::allocator<char>>::str(void)
.text:0810CC0B ;   } // starts at 810CBE6.text:0810CC10                 pop     eax.text:0810CC11                 push    dword ptr [ebp+format].text:0810CC17                 push    6.text:0810CC19 ;   try {.text:0810CC19                 call    _syslog ; <--- Vulnerable call to syslog().text:0810CC19 ;   } // starts at 810CC19

A String object (that contains query:) has the query string appended to it, then is passed directly into _syslog(), which processes format string characters.

Impact

The most likely impact of a successful attack is to crash the server process. A skilled attacker could potentially develop a remote code execution exploit, which would run code on the F5 BIG-IP device as the root user.

Remediation

There is currently no fix for this issue in released BIG-IP software versions. F5 has indicated that an engineering hotfix will be made available. It should be stressed that this issue is only exploitable as an authenticated user of the vulnerable device. So, end users should restrict access to the management port to only trusted individuals (and the linked KB provides a procedure to bind webd to localhost) which is usually good advice anyway.

Rapid7 customers

An authenticated vulnerability check for CVE-2023-22374 will be available in today’s (Feb 1) content-only release. Because F5’s hotfix policy is that hotfixes come with "no warranty of guarantee of usability," please note that hotfixes are not taken into consideration for vulnerability checks within InsightVM.

Timeline

  • December, 2022 – Discovered the vulnerability
  • Tue, Dec 6, 2022 – Reported to F5 SIRT
  • Wed, Dec 7, 2022 – F5 forwarded to the F5 Product Engineering team for analysis
  • Thu, Dec 22, 2022 – F5 confirmed the issue and has started working on a fix
  • Wed, Jan 4, 2023 – Issue reported to CERT/CC (VRF#23-01-TVJZN)
  • Wed, Jan 18, 2023 – F5 provided a draft security advisory, CVSS scoring, and CVE-2023-22374 reservation
  • Wed, Feb 1, 2023 – This public disclosure and F5’s advisory published

Elementary OS 7 released

Post Syndicated from original https://lwn.net/Articles/921854/

Version 7 of
the Ubuntu-based elementary OS distribution has been released.

In the latest version of AppCenter we’ve worked on making app
descriptions more engaging with more information, making it easier
to update to the latest versions of apps, and improving support for
sideloading and alt stores. We’ve also worked on improving
AppCenter’s responsiveness—making sure you can comfortably use it
when tiling and on small displays as well as better using space on
large displays.

Decreasing incident response time for OutSystems with AWS serverless technology

Post Syndicated from Ivo Pinto original https://aws.amazon.com/blogs/architecture/decreasing-incident-response-time-for-outsystems-with-aws-serverless-technology/

Leading modern application platform space OutSystems is a low-code platform that provides tools for companies to develop, deploy, and manage omnichannel enterprise applications.

Security is a top priority at OutSystems. Their Security Operations Center (SOC) deals with thousands of incidents a year, each with a set of response actions that need to be executed as quickly as possible. Providing security at such large scale is a challenge, even for the most well-prepared organizations. Manual and repetitive tasks account for the majority of the response time involved in this process, and decreasing this key metric requires orchestration and automation.

Security orchestration, automation, and response (SOAR) systems are designed to translate security analysts’ manual procedures into automated actions, making them faster and more scalable.

In this blog post, we’ll explore how OutSystems lowered their incident response time by 99 percent by designing and deploying a custom SOAR using Serverless services on AWS.

Solution architecture

Security incidents happen with unknown frequency, making serverless services a natural fit to boost security at OutSystems because of their increased agility and capability to scale to zero.

There are two ways to trigger SOAR actions in this architecture:

  1. Automatically through Security Information and Event Management (SIEM) security incident findings
  2. On-demand through chat application

Using the first method, when a security incident is detected by the SIEM, an event is published to Amazon Simple Notification Service (Amazon SNS). This triggers an AWS Lambda function that creates a ticket in an internal ticketing system. Then the Lambda Playbooks function triggers to decide which playbook to run depending on the incident details.

Each playbook is a set of actions that are executed in response to a trigger. Playbooks are the key component behind automated tasks. OutSystems uses AWS Step Functions to orchestrate the actions and Lambda functions to execute them.

But this solution does not exist in isolation. Depending on the playbook, Step Functions interacts with other components such as AWS Secrets Manager or external APIs.

Using the second method, the on-demand trigger for OutSystems SOAR relies on a chat application. This application calls a Lambda function URL that interacts with the playbooks we just discussed.

Figure 1 represents the high-level architecture of OutSystems’ custom SOAR.

SOAR architecture for AWS

Figure 1. SOAR architecture for AWS

This architecture was deployed with Infrastructure as Code (IaC) using AWS CloudFormation and AWS CodePipeline.

This same IaC architecture is used when new playbooks or updates to existing ones are made. Code changes that are committed to a source control repository trigger the CodePipeline which uses AWS CodeBuild and CloudFormation change sets to deploy the updates to the affected resources.

Use cases

The use cases that OutSystems has deployed playbooks for to date include:

  • SQL injection
  • Unauthorized access to credentials
  • Issuance of new certificates
  • Login brute forces
  • Impossible travel

Let’s explore the Impossible travel use case. Impossible travel happens when a user logs in from one location, and then later logs in from a different location that would be impossible to travel between within the elapsed time.

When the SIEM identifies this behavior, it triggers an alert and the following actions are performed:

  1. A ticket is created
  2. An IP address check is performed in reputation databases, such as AbuseIPDB or VirusTotal
  3. An IP address check is performed in the internal database, and the IP address is added if it is not found
  4. A search is performed for past events with the same IP address
  5. A WHOIS is performed on the IP address
  6. Recent logins of the user are identified in the SIEM, along with all related information
  7. All of this information is automatically added to the ticket. Every step listed here was previously performed manually; a task that took an average of 15 minutes. Now, the process takes just 8 seconds—a 99.1% incident response time improvement.

The following remediation actions can also be automated, along with many others:

Some of these remediation actions are already in place, while others are in development.

Conclusion

At OutSystems, much like at AWS, security is considered “job zero.” It is not only important to be proactive in preventing security incidents, but when they happen, the response must be quick, effective, and as immune to human error as possible.

With the implementation of this custom SOAR, OutSystems reduced the average response time to security incidents by 99%. Tasks that previously took 76 hours of analysts’ time are now accomplished automatically within 31 minutes.

During the evaluation period, SOAR addressed hundreds of real-world incidents with some threat intel use cases being executed thousands of times.

An architecture composed of serverless services ensures OutSystems does not pay for systems that are standing by waiting for work, and at the same time, not compromising on performance.

If you are interested in this topic—how to respond to security incidents using AWS serverless services—be sure you also read the Orchestrating a security incident response with AWS Step Functions and How to get started with security response automation on AWS blog posts.

Хронология на нежеланието да бъде разследван главния прокурор

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

Ясно е, че мнозинството в Народното събрание не иска главния прокурор да може да бъде разследван от независим от него прокурор и съответно да му бъде повдигано обвинение. И ГЕРБ, ДПС и БСП опитват да прикрият това си нежелание зад процедури и неочаквани съюзи. Нека да разгледам хронологията на това нежелание. Не претендирам за пълнота на стъпките до предишния парламент.

1. През 2009 г. Европейският съд за правата на човек осъжда България по делото „Колеви срещу България“ заради недосегаемостта на главния прокурор. Прокурор Колев е бил убит, като има съмнения, че главният прокурор е намесен в убийството, но няма кой да го разследва заради кариерна и организационна зависимост.

2. Накрая на мандата на ГЕРБ, през 2021 г., месец преди разпускането на Народното събрание, е прието изменение на Наказателно-процесуалния кодекс, с което се въвежда механизъм за разследване и повдигане на обвинение. Но този механизъм не е добре обмислен (дали съзнателно или не – не знам), и бива отменен от Конституционния съд по-късно през годината.

3. След обявяването на механизма за противоконституционен, от Демократична България говорим за ефективен механизъм за разследване на главния прокурор в две кампании поред.

4. Възраждане внасят проект за разследване на главния прокурор от шефа на следствието, което противоречи на изискването за независимост (за повече детайли – коментарът на бившия прокурор Янкулов) в началото на 47-мото Народно събрание.

5. Министерство на правосъдието, с министър Йорданова, разработва проект за механизъм за разследване на главния прокурор. Механизмът става условие в Плана за възстановяване и устойчивост, като за да бъде приет, трябва да е получил становище от Венецианската комисия. Нейното заседание е в началото на есента, поради което той не е внесен в 47-мото Народно събрание. Публикуван е за обсъждане на сайта на Министерство на правосъдието. Освен механизма за разследване, в законопроекта се предвижда и ред за обжалване на отказите на прокуратурата да образува досъдебно производство – иначе казано, ограничава „опъването на чадър“ от прокуратурата.

6. На първия ден на настоящото Народно събрание Демократична България внасяме законопроекта, след като вече Венецианската комисия е дала своето становище. След това и Възраждане внасят техния.

7. Законопроектът на Демократична България е разпределен на много комисии, но е гледан от водещата комисия два месеца по-късно – на 11.01. През това време е нямало желание да се разгледа законопроекта. Може би оправдание би било, че се чака законопроектът на Министерски съвет, който доразвива законопроекта, който министър Йорданова „оставя“ в МП. Само че ако имаше желание това да мине, можеше подобренията на МП да бъдат внесени между първо и второ четене. Желание нямаше, съответно това не беше направено.

8. От 11-ти нататък започна едно бавене – първото заседание на правна комисия по този законопроект беше прекратено, а следващото беше седмица по-късно. 6 часа четене на становища, които са изпратени на комисията и тя се е запознала с тях няма никаква полза, освен за бавене.

9. Същата седмица (след 11-ви), в петък предложихме включване на нашия законопроект в дневния ред на пленарното заседание без доклад от водещата комисия, тъй като срокът от два месеца след внасяне е изтекъл. Мнозинството (с участие на ГЕРБ, ДПС и БСП) го отхвърли, за да не наваксаме забавянето, което същото това мнозинство постигна.

10. Законопроектът беше включен в дневния ред за 26.01. Защо не за 25.01 – за да може да се забави, както ще видим в следващите изречения. На 26.01 сутринта залата размени двете точки – тази по законопроекта на Възраждане и другата, с проектите на ДБ и на Министерски съвет. Така на 26.01 до обяд минава проекта на Възраждане. След това започва четене на доклади. Докладът на водещата комисия се чете от няколко човека и отнема около час и половина (абсолютно излишно губене на време). Заради други изменения на НПК, има доклади от общо 8 комисии (като подкрепящите са с по-кратки доклади, но все пак над 2 часа се четат доклади, които всички трябва да са чели). Към 5:20 вземаме почивка, за да направим изслушване на Мета и Телус за модерацията. При обявяване на края на почивката, председателят на комисията Калина Константинова обявява край на заседанието на комисията. В зала ГЕРБ и ДПС правят проверка на кворума и не се регистрират, като по този начин прекратяват заседанието. Опитват да обвинят това липсващите депутати от ПП и ДБ, но дори всички да бяха в зала, кворум нямаше да има, защото когато 100+ депутати от ГЕРБ и ДПС не се регистрират, няма как да има кворум. Така ГЕРБ и ДПС генерират още един ден забавяне.

11. На следващия ден залата приема да продължи разглеждането на НПК и приема този на Министерски съвет (за разследване на главния прокурор, който надгражда проекта на ДБ). Има обаче един детайл – за да започнат да текат сроковете между първо и второ гласуване, когато повече от един законопроект за изменение на един и същи закон е приет на първо четене, трябва комисията да одобри обединен законопроект. От трибуната призоваваме Правна комисия да изготви обобщения законопроект в рамките на деня, но това не се случва. Не се случва и в понеделник. Заседанието на Правна комисия е свикано във вторник. Като контраст – когато се бърза по даден законопроект, такива заседания за одобряване на общи законопроекти се свикват в почивки, и са изцяло формални. Така стана по Изборния кодекс, например. Тук се загубиха още два дни.

12. Във вторник (31.01) има извънредно пленарно заседание. За да започнат да текат срокове по предложения, трябва обобщения законопроект да бъде съобщен в пленарна зала. Тогава могат да се предложат и съкратени срокове. Часове наред или председателят на Правна комисия не изпраща съобщението до председателя на НС, или съобщението се „мотае по коридорите“. Съобщението стига до председателстващия чак когато заседанието е станало закрито, за да приеме докладите на службите за сигурност (поради потенциалното наличие на класифицирана информация). Тогава Надежда Йорданова предлага тридневен срок за предложения. След почивката, поискана от ДБ, ДПС също иска почивка. Може би за да изчислят точно колко човека трябва да гласуват, за да изглежда, че е можело предложението да мине, ако е нямало отсъстващи депутати? (Някой ден бих проверил дали в такива ситуации се вземат данни от системата за достъп, за да е ясно от коя група колко човека има в сградата).

В крайна сметка в зала сме 17 души от ДБ и 40 от ПП (от ДБ има двама отсъстващи за целия ден, една от които е родилата предната вечер Илина Мутафчиева). Първото гласуване на минава, но от ГЕРБ поискват прегласуване. При прегласуването в ГЕРБ промяна няма, но последният човек от Възраждане успява да гласува, а един объркал се от Български възход си сменя гласа от „възъдржал се“ на „за“. Председателстващият пита „г-н Янев, успяхте ли да гласувате“, но справката показва, че Янев не е гласувал, макар да е бил в зала. Крайният резултат е, че ако целите групи на ПП и ДБ са били в зала, е щяло да мине (но разбира се, няма как Илина, която е родила снощи, да е в зала). Съвсем очаквано, веднага след това, Костадинов (Възраждане) обяснява пред журналисти как заради нас не е минал съкратения срок. Днес казва същото в декларация от трибуната. Тази опорка има за цел само едно – да замаскира отказа на мнозинството от ГЕРБ, ДПС и БСП да има реален механизъм за разследване на главния прокурор. Защо този път използват Костадинов за говорител – защото предния път (по 10) изглеждаше доста кухо да обвиниш другите, а ти да не си се регистрирал.

Седмица по седмица, ден по ден, процедурен трик след процедурен трик, ГЕРБ и ДПС, придружени от БСП, отлагат приемането на механизма за разследване на главния прокурор. И не само това – доста други промени, които ограничават безконтролната власт на главния прокурор. Толкова много усилие съсредоточено върху браненето на главния прокурор не е добро начало за предизборна кампания за колегите, но дано в следващия парламент не продължат да измислят нови начини да забавят неизбежното.

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

Passwords Are Terrible (Surprising No One)

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/02/passwords-are-terrible-surprising-no-one.html

This is the result of a security audit:

More than a fifth of the passwords protecting network accounts at the US Department of the Interior—including Password1234, Password1234!, and ChangeItN0w!—were weak enough to be cracked using standard methods, a recently published security audit of the agency found.

[…]

The results weren’t encouraging. In all, the auditors cracked 18,174—or 21 percent—­of the 85,944 cryptographic hashes they tested; 288 of the affected accounts had elevated privileges, and 362 of them belonged to senior government employees. In the first 90 minutes of testing, auditors cracked the hashes for 16 percent of the department’s user accounts.

The audit uncovered another security weakness—the failure to consistently implement multi-factor authentication (MFA). The failure extended to 25—­or 89 percent—­of 28 high-value assets (HVAs), which, when breached, have the potential to severely impact agency operations.

Original story:

To make their point, the watchdog spent less than $15,000 on building a password-cracking rig—a setup of a high-performance computer or several chained together ­- with the computing power designed to take on complex mathematical tasks, like recovering hashed passwords. Within the first 90 minutes, the watchdog was able to recover nearly 14,000 employee passwords, or about 16% of all department accounts, including passwords like ‘Polar_bear65’ and ‘Nationalparks2014!’.

Code to the beat of your own drum during Black History Month 2023

Post Syndicated from Kevin Johnson original https://www.raspberrypi.org/blog/coding-projects-black-history-month-2023/

When we think about a celebration, we also think about how important it is to be intentional about sound. And with this month of February being a celebration of Black history in the USA, we want to help you make some noise to amplify the voices, experiences, and achievements of the Black community.

Two young people using laptops at a Code Club session.

From the past and present, to those still to come in the future, countless remarkable achievements have been made by Black individuals who have chosen to move to the beat of their own drum. Music and sound can be tools to tell stories, to express ourselves, to promote change, to celebrate, and so much more. So take some time this month to make your own music with your young coders and start dancing.                

A young person smiles while using a laptop.
Two young people share their Scratch project on a laptop.

Of course, choosing to dance is not the same as choosing to devote your life to the equality and freedom of all people. But it reminds us that you can incite change by choosing to do what is right, even when you feel like you’re the only one moving to the music. It won’t be long before you see change and meet people you resonate with, and a new sound will develop in which everyone can find their rhythm.

So join us this month as we explore the power of code and music to celebrate Black History Month.

Projects to help you find your rhythm

We’ve selected three of our favourite music-related projects to help you bring a joyful atmosphere to your coding sessions this month. All of the projects are in Scratch, a programming language that uses blocks to help young people develop their confidence in computer programming while they experiment with colours and sounds to make their own projects.  

Drum star | Scratch

Find your rhythm with this clicker game where you earn points by playing the drums in different venues. The project is one of our Explore projects and it includes step-by-step instructions to help young creators develop their skills, confidence, and interest in programming. This makes it a great option for beginners who want to get started with Scratch and programming.

alt=""

Music maker | Scratch

Code to the beat of your own drum — or any instrument you like. Use this project to create your own virtual musical instrument and celebrate a Black musician you admire. For young people who have some experience with Scratch, they may enjoy expressing themselves with this Design project. Our Design projects give young people support to build on their experience to gain more independence coding their own ideas.

alt=""

Binary hero | Scratch

Can you keep up with the beat? Prove it in this game where you play the notes of a song while they scroll down the screen. You could choose to include a song associated with a moment in Black history that is meaningful to you. This project is a great opportunity for young people to expand their programming knowledge to create lists, while they also test their reaction skills with a fun game.

alt=""

For young creators who want to create projects that don’t involve music or sound, check out these projects which can help you to:

Let us know how you’re celebrating Black History Month in your community on Twitter, LinkedIn, Facebook, or Instagram all month long!

Black stories to inspire you to move

Learn about our partnership with Team4Tech and Kenya Connect, with whom we are empowering educators and students in rural Kenya to use the power of coding and computing to benefit their communities.

A young person uses a computer.
  • I Belong in Computer Science: Salome Tirado Okeze

Meet Salome, a computer science student from the UK who shares her experiences and advice for young people interested in finding out where computer science can lead them. Salome was one of the first people we interviewed for our ‘I belong’ campaign to celebrate young role models in computer science.

alt=""

Research to help set the tone  

We believe that creating inclusive and equitable learning environments is essential to supporting all young people to see computer science as an opportunity for them. To help engage young people, especially those who are underrepresented in computer science classrooms, we are carrying out research with teachers to make computing culturally relevant. Our work promoting culturally relevant pedagogy in educational settings in England has been impacted by projects of many US researchers who have already contributed heavily to this area. You can learn about two of these projects in this blog post.

Educators who want to find out how they can use culturally relevant pedagogy with their learners can download our free guidelines today.

An educator explains a computing concept to a learner.

We would also like to invite you to our monthly research seminar on 7 February 2023, when we will be joined by Dr Jean Salac who will be sharing their research on Moving from equity to justice in computing instruction for youth. Dr Salac’s session is part of our current series of seminars that centres on primary school (K–5) teaching and learning of computing. The seminars are free and open to everyone interested in computing education. We hope to see you there! 

I want to register for the seminar

The post Code to the beat of your own drum during Black History Month 2023 appeared first on Raspberry Pi.

The collective thoughts of the interwebz