AWS Security Hub was announced in Andy Jassy's re:Invent 2018 Keynote(46:23) and pitched as "a place to centrally manage security and compliance across your whole AWS environment (applause)" and then went on to announce an array of partners who were part of the initial integration effort (muted applause). While this announcement enjoyed just 3 minutes on centre stage, this is a significant development.

One of the notable developments included in this announcement is the creation by AWS and adoption by AWS and select AWS partners of a standard format for security events called the 'AWS Security Finding' format . This common format is a key enabler of the aggregation of 'Findings' into Security Hub as it pushes the responsibility for conformance onto the findings emitter rather than requiring the aggregator to build and maintain multiple parsers for all findings sources. The AWS services GuardDuty, Macie, and Inspector, if configured, will automatically have their findings aggregated in SecurityHub once it is enabled.

Given that many of the security partners involved compete with one another to some extent or offer Security Operations Centre (SOC) services providing the black box magic of event ingestion and correlation into incidents, one can imagine that the incentive to standardise on a format which could level the playing field just a little bit must not have been great. The inexorable change of the market and the dominant agent of that change together clearly made a compelling case!

The standard findings format ensures that the attributes required for the correlation of findings are present. 'Insights' are light-weight correlation rules, essentially filter and grouping operations to linked to an 'action'. This 'action' as set up in Security Hub is simply an identifier for an event which will be sent to CloudWatch Events if triggered. It is in CloudWatch Events where any notifications, automations, or integrations will be configured. As it stands today, actions must be manually triggered from the 'insight' and cannot be associated and triggered automatically . One assumes that this will be addressed in future releases.

Usefully, some standard findings are made available by AWS for such conditions as 'S3 buckets with sensitive data and public read permissions' which on their own should spare a great deal of pain to AWS customers!

On the theme of aggregation, Security Hub supports a master/member model where the designate master account can invite member accounts to pool findings. Once accepted, the findings from the member account are aggregated in Security Hub in the master. The member has access to view their own findings, while the master has a view of findings from itself and all members. It should be notes that at this time, Security Hub is a regional service.

Under the 'Standards' menu, AWS provides the first of its automated compliance checks 'CIS AWS Foundations' - with 43 automated rules as of 11th December 2018.

Let's take a brief look in practice at how these various concepts and components work together. We'll be working with a single test account rather than trying to demonstrate master/member.

And, indeed, we do have a match output in the AWS Security Finding format :

our subscription to this topic looks like this:

If we view the metrics for this rule, we should should see TriggeredRules reporting a value of 1 . Before long, however, an email will appear in our Inbox with the full raw contents of the finding .

As a PoC, this is interesting, but this is merely a start. CloudWatch Events provides a broad selection of targets, which enable a high degree of versatility, whether you want to push events to another system, generate a ticket in order to engage human specialists, or automate remediation. What can you accomplish? Sign up for the Security Hub preview and share your thoughts and experiences below.

Something to watch is the extent to which the AWS Security Finding format takes on a life of its own outside of AWS. Having been compelled to conform to a standard, does this development serve as a catalyst for further cooperation between vendors or the inspiration behind yet to be conceived OSS projects? There does not appear to have been much movement on Security Device Event Exchange and the Cisco extension CICEE in recent years, just perhaps this is the impetus which has been lacking.

A critical vulnerability in the Portal for ArcGIS component of ArcGIS Enterprise has been discovered, where an ordinary authenticated user can elevate themselves to be administrators of the portal once a set of special steps is taken by that authenticated user. Portal for ArcGIS 10.3 and higher users are impacted.

As this is a critical vulnerability and the exploit not in yet in the wild, we strongly encourage everyone to apply this patch within the next two weeks to minimize risk. If you are not using the latest version of a release, such as 10.5, we have provided a patch for those versions, but recommend moving to at least the latest version of the release such as 10.5.1 so that you can apply the cumulative security patch incorporating all of the available security patches for the product version.

Portal for ArcGIS Security 2018 Update 3 Patch is available for versions 10.6.1, 10.5.1, 10.4.1, and 10.3.1 and is a cumulative security patch for all issues available for the Portal version.

Portal for ArcGIS Privilege Escalation Security Patch is available for versions 10.6, 10.5, 10.4, and 10.3 and is non-cumulative This patch only includes a fix for this specific issue.

A support summary of the issue is availablehere.

Esri Software Security & Privacy Team

The Infrastructure Team at Coinbase has the goal of enabling any engineer in the company to quickly and securely access and deploy complex infrastructure. This effort started with our secure deployment pipelineCodeflow, was extended by our codification tooling GeoEngineer , and utilized by our blockchain infrastructure project Snapchain .

Our latest project to empower engineers was to make it easy and safe to elevate their own permissions temporarily to perform complex infrastructure changes.

Everything that engineers do at Coinbase is locked down by a mechanism that implements consensus. In order to interact with any production environment you must have a quorum of engineers approve the permissions, code, and configuration. This creates strict guardrails around making changes to our production environments along with an audit trail. This also enables us to secure customers funds with confidence.

Our philosophy of consensus also applies to access to critical services such as AWS and GitHub since our production services depend on them. In the past we have manually onboarded employees onto such services with consensus and an audit trail. Manually provisioning accounts to services has been easy for us to do until this year. In 2018 Coinbase has experienced incredible hypergrowth growing from 200 to almost 600 employees. This means that the number of employees joining per week has increased dramatically. Manually provisioning accounts resulted in operational toil. This is an obvious place for us to eliminate toil through automation.

We have built a Single Sign On (SSO) system that fulfills our consensus philosophy by protecting all changes to a user’s permissions via consensus to eliminate this source of toil. The system that we built had the following requirements to meet our high security and productivity standards:

To build this identity provider (a service that authenticates users on behalf of other services) we use a combination of SAML, LDAP, and consensus.

SAML (Security Assertion Markup Language) is the defacto enterprise SSO protocol. It is used to send cryptographically signed assertions about a principal (ie. their permissions) to service providers like AWS and GitHub. These assertions are used to authorize users into their platform. SAML profiles describe the different request-response protocols that identity providers and service providers can use to communicate with each other. SAML bindings describe which lower level communication and messaging mechanisms are used in the steps of SAML profile specifications.

LDAP is a tried-and-true directory service that is typically used to represent organizations in a tree-like structure. It also has secure native authentication mechanisms for users.

In order to understand how consensus is used to protect changes to users’ permissions, we will first explain how consensus is used at Coinbase.

In the software development process at Coinbase engineers can only deploy code to production environments that meet a specific set of checks and requirements. These checks and requirements are numerous but one of the key requirements is that all deployed git branches much be checked via consensus by a tool we wrote called Heimdall. This tool enforces an immutable git history that has ensured all commits have consensus.

The general software development process to deploy code to production environments is as follows:

In our configuration of LDAP we have two directories ― users and groups.

The groups directory describes which groups users are a part of. Service providers use this to translate into permissions specific to that service.

When an engineer would like to elevate their permissions to a service they make a pull request to a repository that is used to build the groups directory. This repository is protected by consensus with Heimdall. This repository then updates the groups directory which is served from a read-only filesystem. The git commit history creates an audit trail which is one of our requirements for compliance.

The users directory contains information about users as well as their cryptographically hashed passwords. Users authenticate against this directory as well as MFA with a push notification from Duo Push .

Most people understand that retail becomes a target for cybercriminals during the holidays. But even businesses not related to the retail sector will often find the holidays their most vulnerable time of year. After all, many individuals (that is, employees) are focused on wrapping up projects before the holidays truly start or are looking ahead to the coming year with the added distraction that the holidays bring.

Businesses need to protect themselves from potential cybersecurity threats during the busy holiday season -- many of which will come in the form of the world’s most commonly used utility, email. In this post, we will take a look at some of the biggest on-premises and cloud email security threats your business faces this holiday season.

The holiday season creates an opportune time for cybercriminals. At the office, employees are often faced with end-of-the-year initiatives and larger overall workloads. Outside of the office, they are juggling holiday parties, travel plans, gift purchasing, and a plethora of other activities. In short, they are extremely busy, have limited time, and not as attentive as they normally would be. As a result, they become far more vulnerable. For example, employees may:

Email, however, is likely the most common way in which your company can be targeted by a cybercriminal. While it varies a bit by industry, employees will often have a lot more to do during this time of year, and in some cases get a lot more email than they normally would. Some of these may come in via their work email, but many more will come in from personal emails that are read on devices connected to your network.

This influx of email and the clever holiday-oriented email subject lines and content that criminals dream up this time of year increase the chance of an employee clicking on a malicious link or responding to a phishing email. Even if your staff is well trained, the chances that they will follow through on that training decreases when they are distracted or in a rush to get everything done before a holiday vacation.

Just as worrisome is when employees are traveling and unable (or unlikely) to access work email, which happens more often during the holidays. Cybercriminals like to wait for periods of time in which businesses are short handed in order to launch attacks. For example, a cybercriminal may use the acquired email credentials for a CMO when that person is out of the country (perhaps made plain by their automated away message). Knowing this, the criminal sends an email from the CMO’s account to the company’s financial department requesting a wire transfer, stressing end-of-year urgency to send the money immediately, a classic Business Email Compromise (BEC) scam. Since the real CMO is out of the country and not easily accessible, he or she may not notice the email exchange until back from their holiday, when it’s too late.

Businesses need to be vigilant about their email security, as email is among the easiest and most popular methods of cyberattack. The high volume of these threats greatly increases the chances that your business will become a target.

In addition to the BEC scheme described above, here are some of the most common on-premises and cloud email security threats you’re likely to experience during the 2018 holidays:

Your organization has to protect itself from email security threats during the holidays. But it can be difficult to do so when your -- and your employees’ -- time and attention is elsewhere. An automated solution can help. Advanced, next-generation solutions don’t just identify traditional threats such as ransomware, they also can identify the hallmarks of phishing schemes and social engineering attempts, and identify when an "employee" may be compromising sensitive information.

Next-generation cybersecurity solutions are able to automatically strip out potentially harmful attachments from emails, thereby reducing the chances that your employees could accidentally fall victim to an attack that results in your network being breached. Further, should an attack still slip through, these solutions are able to detect the anomalous network activity, enabling your security team to quickly remediate these threats before they can do harm to your company’s network and your company’s sales. Through next-generation solutions that can detect email attacks, you can prevent disruption even when employees let down their guard.

Photo credit: pathdoc / Shutterstock

No matter how much we read about hacks and data breaches and the importance of taking solid security precautions, one of the unchangeable truths of the world is that people on average are absolutely terrible when it comes to choosing passwords. We use the same ones over and over, to the delight of hackers, and the ones we come up with tend to be pathetically easy so that we’re able to remember them.

SplashData is out with its eighth annual compilation of the Worst Passwords of the Year, a ranking it produces after evaluating more than 5 million passwords that have been leaked on the Internet. If you use any of these, we can’t stress this enough. As SplashData puts it themselves, anyone using any of these passwords is putting themselves “at substantial risk of being hacked and having their identities stolen.”

Don't Miss : Today’s top deals: Sony headphones, $250 iPad, Instant Pot, Nest, Philips Hue, $25 Fire TV Stick, more

A few notes about this list: 2018 was the fifth straight year that saw these passwords in the Number 1 and 2 spots for being the absolute worst: “123456,” and “password.” The five worst passwords after those 2? They’re all just numerical strings.

SplashData is a provider of password management applications TeamsID, Gpass, and SplashID. “Our hope by publishing this list each year is to convince people to take steps to protect themselves online,” says SplashData CEO Morgan Slain. “It’s a real head-scratcher that with all the risks known, and with so many highly publicized hacks such as Marriott and the National Republican Congressional Committee, that people continue putting themselves at such risk year-after-year.”

Without further ado, here’sSplashData’s “Worst Passwords of 2018” list:

SplashData estimates almost 10% of people have used at least one of these 25 passwords and that some 3% of people have used the worst password, 123456.

Here are some tips from SplashData on how to be better at password security:

1. Use passphrases of twelve characters or more with mixed types of characters.

2. Use a different password for each of your logins. That way, if a hacker gets access to one of your passwords, they will not be able to use it to access other sites.

3. Protect your assets and personal identity by using a password manager to organize passwords, generate secure random passwords, and automatically log into websites.

Image Source: Cultura/REX/Shutterstock

sidestepping a poorly implemented protection, has significant privacy implications!

November 29, 2018

Our research, tools, and writing, are supported by “Friends of Objective-See”

Today’s blog post is brought to you by:

In this short blog post, we’ll detail a trivially exploitable privacy issue that despite Apple’s (rather feeble) attempts to prevent, allows sandboxed applications to surreptitiously spy on unsuspecting users - even on the latest version of macOS!

Note:

This issue was originally disclosed (by yours truly) at Objective-See’s Mac Security Conference: “Objective by the Sea” . This blog post dives more deeply into the technical details of the flaw.

Slides from the talk: “Protecting the Garden of Eden”

From a security and privacy point of view, sandboxes are an excellent idea. In short, within the constraints of a properly designed and implemented sandbox, an application is largely limited in a variety of ways. For example, amongst other constraints, it cannot arbitrarily access user files (i.e. your pictures or downloads), capture keystrokes, or subvert the OS. Hooray!

Of course, any sandbox implementation will have its flaws, allowing malicious applications to either “escape” the sandbox completely, or while still in the sandbox, bypass some specific sandbox constraint. In this post, we’re dealing with the latter, specifically side-stepping Apple’s sandbox constraints on “distributed notifications” in order to gain valuable insight into the environment outside the sandbox and monitor (some) private user and OS activities.

OSX/macOS allows applications or system components to broadcast notifications “ across task boundaries. ” Aptly termed “distributed notifications” such events are broadcast by means of the DistributedNotificationCenter class. Described in the distributed notification class documentation , Apple states this class is a “ notification dispatch mechanism that enables the broadcast of notifications across task boundaries. “

More specifically:

“ A DistributedNotificationCenter instance broadcasts NSNotification objects to objects in other tasks that have registered for the notification with their task’s default distributed notification center. “

As we’ll shortly see, at any given time a myriad of (interesting) notifications are globally broadcast by apps, programs, and system daemons. Tapping into this steam, by registering a global distributed notification listener reveals a lot about the “goings on” of the system, as well as what the user is up to!

To globally register to receive all distributed notification, simply invoke the CFNotificationCenterAddObserver function (shown below) with 'nil' for the 'name' parameter. The callback specified will be invoked anytime a distributed notification is broadcast by anyone.

Here in code, we register a global distributed notification listener (note: the name parameter is nil , to specify we want to listen for all notifications):

Note:

One can also globally register to receive all distributed notifications via a NSDistributedNotificationCenter method:

- (void)addObserver:(id)observer selector:(SEL)selector name:(NSNotificationName)name object:(NSString *)object suspensionBehavior:(NSNotificationSuspensionBehavior)suspensionBehavior;

If we compile and execute the following code, we can begin observing a variety of system events, such as screen locks/unlocks, screen saver start/stop, bluetooth activity, network activity, and user file downloads:

Note:

The value of the ‘CFDictionaryRef userInfo’ and ‘const void *object’ parameters is dependent on the notification. For example for the ‘com.apple.DownloadFileFinished’ notification, the ‘object’ parameter contains the name of the file that was downloaded.

By design, no special permissions are needed to register such a global listener - and this is all well and good. However, in the context of sandbox, obviously such notifications should not be delivered (to a global listener originating the sandbox) as this would, at least from a privacy point of view, clearly violate the foundational concept of sandbox isolation.

Apple clearly (and correctly), realized that from a privacy (and also possibly a security) point of view, a sandboxed application should not be able globally capture distributed notification. As such, if a sandboxed application attempts to globally register for distributed notifications, the OS sandbox will rather sternly block this action:

Ok so Apple’s macOS sandbox clearly seeks to prevent malicious applications (running in the sandbox) from globally sniffing distributed notifications: *** attempt to register for all distributed notifications thwarted by sandboxing

All is good?

Unfortunately, not at all! Contrary to Apple’s pontifications, it seems security at Cupertino is often approached rather lackadaisically. In other words, it’s often not really thought through. Their attempts to block the receiving of distributed notifications (globally) from within the sandbox, is a perfect example of this…

A fully patched Mojave box (and likely those running any other versions of macOS) fails to adequately prevent sandboxed applications from receiving (possibly sensitive) distributed notifications. Though Apple prevents such an application from registering to receive distributed notifications globally, (passing in 'nil' for the 'name' parameter), there is nothing preventing a sandboxed application from registration to receive any notification by name (e.g. com.apple.DownloadFileFinished ). Thus, a malicious application can trivially circumvent Apple’s (weak) sandboxing attempts, by simply registering any (and all?) distributed notifications directly by name. Though this takes a few extra lines of code, the affect is that any application can cumulatively register to receive (capture) all distributed notifications - even within the sandbox!

Let’s look at an example. Say a malicious application wants to monitor user downloads. When executed in the context of the macOS sandbox, normally this is something that would be strictly prohibited - and rightly so! By definition, a sandbox seeks to provide an isolated environment, protecting both the user’s security and privacy.

However, by registering to receive the com.apple.DownloadFileFinished distributed notification by name, the (sandboxed) application can still surreptitiously monitor all files the user downloads:

Then, write some code to listen for the com.apple.DownloadFileFinished distributed notification:

Running sniffsniff from within the macOS sandbox, even on a fully patched Mojave box, rather surprisingly allows us to surreptitiously monitor the user’s downloads:

Note:

The ‘com.apple.DownloadFileFinished’ distributed notification appears to only be broadcast for files downloaded from a user’s browser. However, this includes those downloaded in incognito mode!

Now, it’s important to note that though we can now monitor user downloads from within the sandbox, we can’t actually read the contents of such files due to other sandboxing rules. However, file names themselves, can be rather implicative…

As we must register for each notification by name (in order to circumvent the sandbox protections), a valid question is how to determine the names of notification of interest (i.e. 'com.apple.DownloadFileFinished' , etc.) Thought there may be a more comprehensive solution, I choose to simply install a global listener for all distributed notifications (of course this had to be done outside the sandbox), then simply observe what notification names. Returning to the sandbox, we can then register for any notifications of interest (by name!).

Thought we could utilize the code mentioned earlier in this post, I instead made use of the powerful monitor capabilities of Digita Security ’s (soon to be released) MonitorKit . As this framework contains a monitor to globally observe distributed notifications, in a few lines of code we can activate said monitor and begin to receive the names of all broadcast distributed notifications:

Note:

OMG Swift code!? …I know

Executing this code reveals some interesting distributed notifications (that a malicious sandboxed application could register to observe):

Newly Installed Applications:

com.apple.LaunchServices.applicationRegistered

Opened Source Code Files:

原标题：新一代杀毒策略 “组合拳”打败网络“高级黑”

美国FBI（联邦调查局）一位高管曾说：世界上只有两种企业，一种是知道自己已被黑客APT入侵的；另一种是还浑然未知的。

APT指高级持续性威胁（Advanced Persistent Threat），它的“高级”在于“用间谍打头阵”。例如，谷歌遭受的著名的“极光行动”中，黑客研究了一位谷歌普通员工与好友的共同爱好，伪装成其好友向其发送邮件，员工访问邮件后中招，谷歌内部终端被未知恶意程序渗透数月，窃取了大量信息。

“它潜伏下来，不做什么坏事，每天像正常‘员工’一样来系统‘上班’，慢慢的传统安全体系会认为它并没有攻击的属性。”亚信安全通用安全产品总经理童宁解释，APT的善伪装、善潜伏、伺机而动，让网络安全的“老三样”（防火墙、入侵检测、杀毒软件）防不胜防，迫切需要一种全新的网络安全治理策略。为此，近日亚信安全发布安全高级威胁治理XDR战略，将发现、响应等能力组合起来，从监测、发现、验伤、应对、止损等多个节点上加强安全治理，打出安全“组合拳”，拆穿黑客中的间谍组织以及背后的主脑“黑手”。

现实中的案件发生后，警方会把周边的摄像头数据全部调出来，关联一下，找到人物和时间线索，很快可以抓到罪犯。但是在虚拟的网络环境里，人们看不到人，看到的只有程序、算法、文件等虚拟的字符串，如何锁定黑客呢？

“不同的黑客有不同的‘招法’，就像我们在武侠故事里经常看到的每一个派别都有自己的招法，其实在安全行业里面也是这样，一个黑客是哪个组织的，可以通过看他的攻击手法和特征来判断。”亚信安全通用产品管理副总经理刘政平说，因此针对黑客的行为去建立一些模型或者规则，可以对黑客的攻击进行分析判断，这样的研究被称为IOC，即黑客攻击行为的研究。因此，情报机制非常重要，“虽然黑客在暗、我们在明，但将他们的蛛丝马迹综合起来，将非常有助于对未知威胁的防范。”

一个企业对于威胁的侦测能力与其掌握的威胁情报体量和分析威胁情报的能力密切相关。这就好比一个人的知识广度和分析能力决定了他的认知能力。如何能够对于威胁既不“风声鹤唳”，也不“马虎大意”呢？

为了更准确预测黑客试探背后的威胁，亚信安全形成了本地和云端威胁情报双回路的体系。刘政平解释，比如当企业中有大量的网络数据流，或者恶意文本，该体系可以据此通过威胁情报去检索，看看这种东西有没有在企业其他地方出现过、发生过，它的攻击本质是什么，如何预防。如果本地没有匹配的威胁情报，将进一步把这些异常表现放到云端威胁情报库匹配，寻找蛛丝马迹。“前者是基于我们帮助企业来做相关的知识库和知识体系；后者是购买、共建的全球范围情报体系。”刘政平说，这两个体系互为补充、互通有无。当本地威胁情报确认后，会交给云端威胁情报共享给全球的其他用户使用。其他用户的本地情报也会参与组建威胁情报，共享共用。

有安全人士慨叹：有了APT，网络的世界也不再是“非黑即白”了。

以往的病毒就是病毒，它们的特征会被集合进病毒库，列进“黑名单”中。系统不断更新病毒库，就能不断识别这些被通缉的“病毒”。“人们越来越认识到，防范已知威胁远远不够，未知威胁、高级威胁开始对我们的企业产生巨大的破坏。”亚信安全产品总监白日说，例如，伊朗布什尔核电站遭到Stuxnet蠕虫攻击、乌克兰电厂的勒索病毒爆发……这意味着杀毒软件、身份认证、防火墙的“防守打法”开始不奏效了。

2010年开始，包括机器学习、行为学习、大数据、关联分析在内的可预测技术开始帮助人们发现未知的可疑威胁。然而，单纯地发现带来的是“告警”无数的窘况。

“就好像每天有无数的嫌犯进入警察的视野，怎么分辨转变成主要问题。”白日说，企业需要处理和响应的威胁告警越来越多，相当大部分需要人工进行干预。企业的痛点是，人力不够，不会处理。

“企业看到了告警，但看不懂威胁，不知道该如何判断威胁是不是真实发生了，也不知道该怎么去确认这个威胁的本质，弄清威胁的攻击者有什么意图，随后会产生什么样的影响。”白日解释，也就是说，大部分收到威胁告警的企业不知道下一步怎么去作定性和定量的分析，定性是弄清楚黑客的意图，定量是弄清损失情况及被攻击到哪一步。

“定性分析首先判断告警是真还是假；其次判断威胁的本质是经济类的犯罪，还是民事类的犯罪，例如类似于加密DDoS软件攻击，还是一个恶意钓鱼的攻击，或挖矿攻击等，通过攻击模式判断意图。”白日解释，深度威胁分析设备可以在沙箱的环境下，高效率地模拟运行外部攻击，判断攻击意图。

定量分析通过网络取证和主机取证的技术，把黑客的进入路径、留下的痕迹进行追踪和分析。白日解释，就如同在小区的摄像头上发现黑客进入到小区之后怎么进入到家里，又做了什么事情一样，还原事件的经过。通过进行场景回溯，能够得知网络上的主机或者终端遭受哪些感染、破坏或窃取。

掌握了一切情报，并且还原了案件的发生，最终是为了实施“抓捕”。

“为了做到快速响应必须有‘预案’，我们可以根据威胁的性质，通过威胁响应的脚本来执行相关的响应策略。”童宁解释，例如接到了加密的勒索邮件攻击，可以先到邮件服务器上把相关的邮件删除，然后通过终端（电脑）来做进一步的恢复处理，最后再在网关上建“防护网”防止类似的加密勒索邮件再次攻击。

“预案”是为了告诉企业，在受到某类攻击之后，按照一定的流程操作就可以把损失或影响减到最小，并且提高自身的防护能力。

“我们提出通过精密编排能力打造一套安全联动运维体系的理念。”白日表示，利用精密编排的联动安全解决方案将安全产品以及安全流程连接和整合起来，通过全面收集的安全数据和告警，集成人工专家以及机器学习的力量来进行事故分析。

为此，亚信安全提出将整个威胁发现、处理、响应流程中的“准备、发现、分析、遏制、消除、恢复、优化”7个阶段整合为XDR方案。

刘政平解释：“X是指各种可能的场景，不管黑客在什么场景攻击，工业还是车联网，都要有相应的应对方式。D是指传感器，在虚拟世界，不管是在云的架构上，还是网络架构上，还是在终端层面，都要有不同的监控机制和数据的还原机制。R是指响应，通过精密编排，根据不同的业务特征、不同的攻击来编排精准的响应，而且越来越倾向于自动化。”

什么样的技术能让响应来得更快、更简单？

童宁认为，“红客”经验的积累和提炼，所形成的响应预案将能够推动APT治理能力的进化。“XDR是一个开放的方案，需要未来更多的经验、数据和技术的积累，目的是用融合力改变业内分散片面的堆叠式的安全应对‘招数’，形成‘组合拳’，应对处心积虑的APT。”

(责编：毕磊、杨波)

Finland announced plans for a digital drivers license this year, and several U.S. States are running similar pilot programs of their own. So far, digital drivers license systems have been fairly limited, but a report by IEEE Spectrum claims that could change in Louisiana soon. According to the report, the developers of the app LA Wallet claim that "bars, restaurants, grocery stores and other retailers" will be allowed to accept digital IDs as proof of age next week. The founder of the app company claims about 71,000 people have downloaded the app, but so far, only police offers are required to accept it as a form of ID, limiting its usage. Spectrum points out that it would be possible to steal someones digital identity in the same way that credit card info is stolen, but there are major security benefits to the system too, and Louisiana has no plans to make plastic IDs obsolete yet.

Discussion

Posted byalphaatlas 9:56 AM (CST)

激增的网络攻击面，庞大的漏洞量，复杂的威胁场景以及新的业务需求等诸多因素，都在呼吁新的网络风险管理模型的出现和运用。

当前所使用的网络风险管理模式显然已经无法适应时代的发展需求。虽然网络风险管理对于企业高管而言比以往任何时候都更为重要，但是鉴于不断激增的攻击面，庞大的漏洞量以及复杂的威胁场景等因素，对于CISO和网络安全团队而言，想要有效地实现网络风险管理却变得更为困难。

即将发布的ESG最新研究表明，过去发挥过作用的网络风险管理模型如今已经不再是一种合适的选择，以下是部分调查结果提要：

企业管理者的参与程度远远超过以往。几年前，企业高管的目标并不是获取真正强大的安全性，他们想要的只是足够好的安全性就够了。当时的安全专业人士对这些并未付诸全力的网络安全工作感到遗憾和失落，他们迫切渴望拥有具备网络安全专业知识的首席执行官，能够真正投资于强大的网络安全控制和监督工作。ESG数据表明，如今企业高管和董事会的参与度和网络安全需求都要远胜以往。这迫使CISO和信息安全团队收集和分析更多的网络风险数据，并以业务友好型方式将其呈现给用户。数据表明，这已经推动了一种新的、更全面的网络风险管理模式的出现。

网络安全支出持续增加，但也出现越来越多的限制。网络安全预算每年都在增长，并且这种趋势还会持续下去。事实上，企业高管们确实愿意增加支出以保护他们的组织，但同时他们也希望更好地了解他们的钱究竟花到了什么地方？获得了哪些投资回报？

例如，如果预算增加，也就是CISO明年要求 120万美元 网络安全支出而不是原计划的100万美元，那么首席财务官（CFO）就会希望了解这笔钱用到了哪些地方？企业为此获得了哪些额外保护？企业高管、GRC经理和网络安全专业人员正试图通过使用模糊指标分析不完整数据来弄清楚如何衡量网络安全支出的投资回报率。这里迫切需要改进。

所有网络风险管理投入都在快速增长，基本的网络风险管理公式如下所示：

所以，这就是问题所在――所有的一切都在迅速增长。整体攻击面（即设备、数据、基于云的工作负载、应用程序等）正在增长，从而导致更多的安全漏洞。例如，ESG研究中的一大亮点就是，各组织业务合作伙伴对第三方风险管理的需求日益增长，以防止发生类似OPM和Target的间接攻击事件。

与此同时，威胁也正变得更具针对性和复杂性。就其产生的后果而言，企业将需要处理更多的风险类型，包括财务风险、操作风险以及声誉风险等等。将所有这些变化叠加在一起，网络风险管理工作量就会不断增加并且变得更为专业化，而不良的网络风险管理实践所造成的后果必然是高风险、高成本的。

根本不存在网络风险管理基准这样的事情。风险管理任务――例如漏洞扫描、第三方风险审计以及渗透测试等――始终都是以定期（每月一次、每季度一次、每年多次等）和独立的方式进行。通常而言，这些活动是由审计师、法律法规甚至业务合作伙伴进行指导，而不是任何具有凝聚力和整体性风险管理策略进行指导。

这就是该方法的问题所在――一切都在不断变化，网络风险管理的每个方面都是相互关联的。因此，当一件事发生变化时，它就会影响其他一切。您如何做到在任何时间点对网络风险管理进行基准测试？答案是您不能！这也就意味着，我们必须接受这种认识，并努力进行持续的风险管理测量。

该研究为我们描绘了一幅清晰的图景： 网络风险管理对于管理人员来说变得越来越重要，但对于CISO和网络安全团队来说则更为困难。

显然，当前的网络风险管理模式已被打破，必须做出改变，而这种变化很快就会出现在我们面前。

需求：负责识别和缓解特别针对内部员工的攻击方法及漏洞的安全主管。

很明显，终端用户是大多数重大攻击的主要攻击途径。无论是用网络钓鱼、传统社会工程，还是通过物理入侵，高级攻击者很清楚从用户下手远比探测技术漏洞更容易找到进入公司的有效入口点。同样重要的是，善意用户造成的伤害总的说来比恶意用户造成的伤害还大。因此，需通过意识培训来让用户更能灵活应变，更具恢复力。

现实是，意识培训某种程度上有效，但需要做的事还有很多。

需设置相关技术手段预先阻止用户的危险动作。在安全界，90%的工作场所意外事故都可以通过创建一个能防止员工暴露在危险情况下的环境而得到避免。比如说，在员工经常被叉车撞到的工厂里，可以在过道上画线，开辟明显的走道。这一简单的改变就几乎规避了所有涉及叉车的事故。仅有的零星事故也是因为行人低头看手机太投入而自己撞到叉车上的。

网络安全世界里，创建安全环境意味着运用反恶意软件程序、垃圾邮件过滤器和PC防护措施来阻止用户安装软件。创建一个安全的环境不仅可以过滤掉 99.9% 的潜在攻击，让威胁根本沾不到用户的边儿，还能阻止来自用户自身的破坏或伤害。但很明显，仍有攻击能够突破防线，所以意识培训仍是减少风险的必备措施。

意识培训项目应聚焦用户该怎样恰当地完成自身工作，而不是恐吓他们应该惧怕哪些行为。这就涉及到恰当监管的概念了。用户不可能识别出所有可能的骗局，但他们至少应能够遵循恰当的动作规程。

虽然基本上大多数公司企业都有某种形式的软件来防止用户遭到侵害，有一定的意识培训和类似于策略或规程的东西，但这些工作往往没有形成联动，很零散和随意，并没有专门针对特定攻击或用户行为的工作。

为解决这一问题，需设置负责识别涉及人员的不同攻击方法和漏洞的职位，姑且称之为人力安全官(HSO)吧。HSO审查可能出现问题的地方，指出预防、检测和响应这些攻击或用户行为的最优方法。

有些人或许会以为这是CISO或意识培训项目经理的工作。现实是，意识培训人员的工作非常具体，专注提供信息以令员工改善其安全相关的行为。意识培训团队并没有义务，也无权负责阻止和缓解漏洞的方方面面工作。意识培训团队应向HSO报告。

HSO负责确定与人相关的漏洞存在的地方，专注协调漏洞缓解工作，也就是检查底层业务过程和确定能有效缓解漏洞的最佳技术运营过程组合。然后，HSO还确保意识培训团队将精力集中在解决员工应如何正确完成自己的工作上。

由CISO来负起HSO的职责固然不错，但具有一定规模的企业里，CISO应有一个团队可以分担责任。就好像CISO手下有不同的人各自负责网络安全、事件响应和监管，也应有HSO来专门负责处理涉及人员的所有漏洞。这一角色应与传统意识培训角色区分开来。

FIT 2019大会会期为2018年12月12日-13日，今日已圆满落下帷幕。昨天的大会主论坛议程聚焦「全球高峰会」、「WitAwards颁奖盛典」、「X-TECH技术派对」、「HACK DEMO」四大版块内容，同时「中国首席信息安全官高峰论坛」、「漏洞马拉松线下邀请赛」也在特色分会场同期举行。回顾首日盛况，请看： 安全圈年终大趴，FIT 2019首日盛况全程回顾

今天的大会主论坛包含「 WIT2018现场最受欢迎奖颁奖 」和「前沿安全神盾局」两大主题，此外独立分设「白帽LIVE」及 「企业安全俱乐部」两大分论坛，与来自全球的安全从业者、优秀技术专家、企业安全建设者、白帽专家、研究机构等同展开演讲与探讨。在今天的主论坛上，我们通过现场投票的方式角逐出了“WIT2018现场最受欢迎奖”，演讲嘉宾与我们分享了2018年度安全行业创新硕果，共同探索和展望未来安全新边界。

本次WitAwards 2018采用7+1的形式，在七大奖项――年度创新产品、年度技术变革、年度品牌影响力、年度安全人物、年度国家力量、年度安全团队、年度热门产品及服务的基础上，组委会特别新设「WIT现场最受欢迎奖」，旨在为获奖者提供更多展示核心技术和产品的机会。

入围本次WIT 2018现场最受欢迎奖角逐的有「年度创新产品」腾讯云、「年度安全团队」无糖信息、「年度技术变革」百度安全以及「年度安全人物」看雪学院段钢。在今天的大会现场，经过观众与评委的共同票选，WIT 2018现场最受欢迎奖最终花落 「百度安全」 。

物联网、人工智能、区块链、互联网+等前沿客季在2018年引起了一波又一波的话题热潮，逐渐成为信息时代产业发展的主要技术经济形态，它们在各种社会领域中的参与度越来越高。在新趋势、新变化带来便利的同时，网络安全隐患日益彰显，安全隐患源头与种类越来越多，成为了影响行业发展乃至国家安全的重要因素。FIT 2019第二日主论坛特设「前沿安全神盾局」版块，汇聚国内外顶级专家学者，带来多个新鲜议题，共话前沿安全。

率先上台的是海康威视CSO王滨，带来的议题是《IoT安全的To B和To C》。他从公众眼中的IoT安全和安全研究人员眼中的安全作为出发点讨论了他对于“To B”和”To C”的区别理解，对于目前的IoT设备安全态势而言，这是一种很好的厘清方式。因为对于C端而言，消费者看到的很多安全方面的报道都存在很大的局限性，因为很多问题的根源来自于上游设备，而不是IoT本身。

要做好 IoT to C 的安全，首先要做好云安全，其次是 APP安全、设备安全、端到端加密以及口令安全。由于开放接口多、用户安全意识淡薄、系统网络环境复杂、历史问题堆积、纵深防御难实施等多个问题，IoT to B 的安全需要厂商提供更高的产品安全需求，同时为用户提供轻管理的安全防护方案。

尤其是漏洞这一块，王滨还有以下特别呼吁：

目前业界遵循的90天的漏洞披露策略对于无有效升级途径的物联网设备并不适用；POC的检测更推荐采用版本检测的方式；用户设置周期性固件更新计划任务，弱口令一定要避免；厂商加强设备的安全设计、开发、测试和应急响应；行业主管机构必须要有强制的检查和通报机制。

百度安全工程师汪明伟在他的议题《Apollo智能网联汽车信息安全实践》中表示：

随着车联网程度层层深入，随之对于车联网的攻击手段花样迭出。虽是大势所趋，但安全性上的内忧外患不解决，用户始终对智能网联汽车望而却步，甚至随时都可能成为交通环境中的定时炸弹。

百度安全实验室在车联网这一领域已经深耕了15年，积累了80款车型数据。2016年8月，实验室实现了国内首例完整入侵案例，如何通过层层步骤接管车辆。从实践经验出发，汪明伟谈到：

解决车联网的内忧外患问题要从流程端和技术端双管齐下。围绕云、车机、网关、ECU四大领域构建快速反应能力、应用和系统可信体系、隔离及检测解决方案、源以及内容的可信架构，最终实现完整的骑着信息安全测试体系。此外，建立专门的机制，尤其是决策层的推动非常关键。

IoT市场规模极具扩张，设备数量大大增长也导致了DDoS攻击的攻击面、攻击量、攻击效果大大提升。骇极安全CEO Zenia从攻击者的思路出发，以「协议逆向」为突破口讨论了IoT安全，她带来的议题是《IoT攻击实践：高效协议分析》。

针对如何高效实现协议逆向，Zenia提出了“进化树”的理念：

在进化系统中，影响生物特征变化巨大的基因（例如控制肺叶和腮体征变化等）其基因多样性变化率远远小于在功能和体征上引起较小变化的基因；

同样这种统计特征出现在一些IoT协议中，例如设备标识符这类决定设备唯一性的字段（基因）在一堆协议数据中基本保持不变，其变化率远远小于那些控制数据字段，例如温度，亮度等操作数据，也就是说字段变化次数: 设备标识符 < 操作标识符 < 数据字段。

因此通过聚类分析，跟踪标识符来：

聚类噪声信号，可以定向的分析有用数据；可以快速标识出变化字节；通过状态机有效识别出信号的关联关系，避免在繁杂的数据中寻找关联。

最终，实现对未知协议的安全测试的能力提升，满足大量安全检测需求，构建自动化FUZZ平台。

“前沿安全神盾局” 下午的下午场首先由联想安全实验室研究员杨欢带来了《巧用EvilUSB攻击智能路由器》的议题分享，在现场带来了智能路由器攻击测试的演示视频。

BadUSB安全漏洞是在2014年由国外安全研究人员发现并公布于Blackhat大会上的，目前市面上仍存在多款路由器都具有相同的安全问题。杨欢通过对该漏洞的发现过程、利用过程，以及针对国内两款路由器发动攻击获取路由器Shell的讲解和演示，详细演示了包含开启危险方法、openwrt-rpcd服务ACL配置错误等多洞结合getshell以及绕过有限制的二次命令注入漏洞。

通过现场讲解和展示，杨欢总结出三条安全建议和防护方法：

配置项的审计比源代码审计更为重要；对于无关的功能模块应当予以删除。以usb存储为例，ext文件系统可以不予支持； 用正确的协议实现正确的功能。

接着讲IoT～Rokid公司安全负责人白嘎力与大家分享“智能IoT安全遇到的挑战”。白嘎力表示预计2020年底，将有10亿设备接入物联网，如此大体量的设备面临着4个维度威胁：硬件、软件、云安全、设备互联和4个严重态势：车联网、智慧医疗、智慧城市、智能家居。

很多智能设备也做了安全防护，但是内部存在开放的可调试接口，只要打开外壳即可访问内部系统。还有部分语音控制模块具备设备操作功能，如果通过模拟声纹的方式来进行攻击可轻易得手。包括版本更新机制、OTA劫持等针对弱网络发起的攻击也很普遍。此外AI等新兴技术在进入安全领域的同时也带来了很多安全风险，比如AI对抗：算法样本对抗AI模型或者算法被攻击，导致人工智能所驱动识别系统出现混乱、误判或者失效；攻击者还可以通过修改现有的训练集生成恶意样本，比如病毒样本的优化，攻击载荷的逃避监测系统等等案例。

白嘎力提出了5个关键的安全加固节点：

安全审计：代码中的安全漏洞进行审计；安全SDK：安全开发生命周期引入，标准化；代码保护：程序核心代码逻辑进行保护；加固：加固、加壳子防止易被逆向破解；IoT平台：风险及时感知，实时监控监测。

除了IoT，AI无疑也是当今的前沿技术。来自斗象科技的高级研究员孟雷以图模型的异常检测为例，讲述AI的安全实践。他带来的议题是《AI安全实践：探索图模型异常检测》。

从设立问题到构建模型，再到人工设立异常阈值检测，最后使用多目标回归模型实现动态阈值，最终获得更精准检测。孟雷提出了一个完整的AI图模型检测。其中的核心是图节点角色模型：

从多个设备告警日志中，抽取关联信息单元，构成告警关联图。根据图方法中的计算指标，对原始告警依赖图做递归特征提取，生成特征矩阵。依据前置的角色度量属性，对特征矩阵做非负矩阵分解，计算每个节点各角色概率分布信息。生成各节点角色分布图

今天我的生活越来越数字化，每天都在产生大量网络安全问题，为了保障安全而在外围部署大量解决方案和节点，这样的会产生大量的数据。面对如此海量的数据，通过构建攻击链图模型可解构网络攻击方式，提供更强的可视性和多设备检测融合分析支持。

如今全球网络犯罪组织在不断进化，很多环节或攻击技术都用到了AI，飞塔中国技术总监张略带来了《威胁与安全AI战场上的决斗》的议题分享，聊一聊安全领域的AI对抗。

不断进化的网络犯罪组织也应用了AI技术，网络安全威胁在AI的加持下也发生了如下的变化：

自动识别出变种模式被发觉，并自动改变变种模式；自动发现并攻击高价值目标（震网病毒）；自动躲避疑似蜜罐，并释放假病毒，迷惑防御者；自动撰写，并发送给高价值目标钓鱼邮件；自动识别防御体系，并采用绕过策略和变种。

一言以蔽之，AI和自动化显著降低了攻击时间，速度是未来AI对决的主题。

张略表示：AI在国内安全领域的应用大体上还处于机器学习和深度学习阶段，还没有真正达到人工智能的水平。算法并不是现阶段发展AI安全技术的最大堡垒，而是样本的量、训练和反馈的持续性远远不够，需要行业共同努力。

360企业安全云影实验室负责人计东带来的议题是《多维度对抗Windows Applocker》。首先，他从三个维度指出了对抗安全策略的意义：

运维视角：采用系统安全策略等手段提高系统的安全性；黑客视角：寻求系统中自带数字签名的可执行文件或脚本、程序集，通过它们旁路攻击绕过安全策略；终极目的：实现低权限下让恶意文件突破策略运行。

在现场的展示中，他从Powershell入手，假设当前系统已经限制了Powershell的执行，该如何突破？切入点就是多种“攻击向量”，包括MSBuild+csproj、CL_LoadAssembly、InstallUtil和Regasm/Regsvcs。

在完成展示后，他还和与会观众分享了一款360360企业安全云影实验室出品的开源工具：

支持Metasploit ShellCode，自动生成攻击向量（可执行文件或程序集）；支持Regasm、InstallUtil 两种方式载入；项目地址： https://github.com/Ivan1ee/Regasm_InstallUtil_ApplockerBypass 。

以太坊的出现直接将区块链技术的发展带入到了2.0时代。随着相关技术越来越成熟，而攻击于防御的对抗方式也逐步升级，以太坊作为智能合约的先行者，在区块链主链技术实现中具有一定代表性。

很多人都把注意力放在了合约的安全性上，而忽略了对于行为的检测。针对这样的现状，玄猫科技安全研究员叶树佳带来《以太坊态势感知系统》议题分享，阐述了对合约、节点、账户等层面监控与分析的概念和时间，并为合约蜜罐、安全事件、异常转账、钓鱼诈骗、非法交易等进行预警并追踪溯源提供了思路。

他也提出了对区块链安全领域的展望：区块链的安全性逐步提高；攻击方式更加深入，细分；安全产品种类会愈加丰富。

还有一款开源shockwave工具分享： https://github.com/XuanMaoSecLab/shockwave，支持爬取合约、静态检测、regex/match、人工审计等功能。

分会场――企业安全俱乐部

The inaugural Binance SAFU Hackathon will bring blockchain developer teams from around the world to build a safer environment for users to exchange cryptocurrencies

Winning teams stand to win US$100,000 in prizes

SINGAPORE, 14 December 2018 Binance , the world’s leading cryptocurrency exchange , will hold the first Binance SAFU Hackathon in Singapore on 19 and 20 January, 2019. The 32-hour round-the-clock hackathon will empower blockchain engineers to rapidly prototype blockchain solutions to solve problems identified in systems we have in place today.

With the theme ‘ Query Platform for Address Security: Is the transaction address you are sending your crypto to SAFU?’ , the Binance SAFU Hackathon encourages long-term, sustainable growth of the blockchain industry, calling for top developers from around the world to build a safer community where users are protected from scams, hackers and money laundering.

To find the best global talent to compete in the Binance SAFU Hackathon, Binance has partnered with different groups to hold pre-hackathons in San Francisco, Seoul, Singapore and Hong Kong, from December to January. The first pre-hackathon was held in San Francisco on 11 December, 2018. To qualify for the final Binance SAFU Hackathon in Singapore, developers who missed the SF event still have a chance to join one of the remaining three pre-hackathons. For more information on registration for the pre-hackathons, do follow Binance Blockchain Week on Twitter .

An esteemed panel of judges will select the hackathon champions based on quality of technology, innovation, demo and pitch. Winners will split a prize pool of US$100,000 in BNB, have a chance to meet senior leadership from Binance, and potential access to incubation programs run by Binance Labs , the investment arm of Binance, and Tribe Accelerator, a Singapore government-backed blockchain accelerator.

Binance SAFU Hackathon welcomes any developers age 18 or older who are passionate about building a safer digital asset world for the future. Attendees can apply on the event website as individuals or with a team of no more than five. Registration for the hackathon is open until 9 January, 2019.

The Binance SAFU Hackathon is part of the inaugural Binance Blockchain Week from 19 to 22 January, alongside the Binance Conference that brings together over 2,000 industry leaders across Blockchain, traditional enterprises and governments.

To join the Hackathon, please register at https://www.binancefair.com/safu-hackathon/

For further updates, follow us on Twitter at https://twitter.com/eventbinance .

Binance is a Blockchain ecosystem comprised of Exchange, Labs, Launchpad, Info, Academy, Research, Trust Wallet and Charity.

Binance Exchange is the leading global cryptocurrency exchange, with users from over 190 countries and regions. Capable of processing more than 1.4 million orders per second, Binance Exchange is the largest crypto exchange by trade volume and one of the fastest in the world. The platform focuses on security, robustness, and execution speed ― attracting enthusiasts and professional traders alike.

For more information on Binance, please proceed here .

For media enquiries, please contact:

Victoria Mak +65 9173 3801

Ang Hwee Min

+65 8698 0456

Note: Tokens on the Bitcoin Core (segwit) Chain are Referred to as BTC coins. Bitcoin Satoshi Vision ( BSV ) is today the only Bitcoin implementation that follows Satoshi Nakamoto’s original whitepaper for Peer to Peer Electronic Cash. Bitcoin BSV is the only major public blockchain that maintains the original vision forBitcoin as fast, frictionless, electronic cash.

The newsletter consists of high-level executive summary of most of the important news, articles, data breaches and Microsoft patches details that have been published on information security. Each news item is very briefly summarized and includes a reference on the web for detailed information. We have tried to keep you updated with the ongoing news in the cyber world to keep you safe from being compromised or hacked.

Click below to download our newsletter.

<b></b><b><a href="http://blog.isecurion.com/wp-content/uploads/2018/12/Newsletter-December-2018.pdf" target="_blank" rel="attachment noopener wp-att-430">ISECURION Newsletter December</a> </b>

南都讯 记者王靖豪 近日，珠海市公安局网络警察支队公布了2018年“成绩单”，网络安全案(事)件同比减少30%以上。今年以来，网警支队采取“现场宣讲+传统媒体+新媒体”的立体宣传模式，充分利用报刊、电台、电视台、手机短信，以及网站、微信公众号等新媒体，有效提高了珠海网络安全防范意识和技术水平。

2018年以来，网警支队先后前往人力资源和社会保障局、省武警五支队、城市职业学院、金山软件公司等18家单位召开网络安全与等级保护专题培训;前往青少年活动中心、北师大珠海学院等组织4场宣传活动。今年10月18日，珠海市公安局网警支队指导，珠海市信息协会主办，中国电信股份有限公司珠海分公司承办的“网络安全法及网络安全等级保护”论坛在珠海信息大厦“互联网+”展示厅召开，100多位来自珠海市信息协会成员单位、相关政府机构、相关领域的专家学者、从业人员参加了论坛。

网警支队利用传统媒体和新媒体手段进行广泛宣传，如依托报纸发新闻报道，联合电台制作防范网络安全节目，在网站制作在线访谈节目等，免费向市民推送诸如安全使用公共W iFi、个人网络安全提醒、等级保护知识普及等短信23万余条，共计11期。

在重大突发事件面前，如今年“山竹”台风袭击珠海之际，网络上的谣言信息非常多，“珠海网警巡查执法”在各大平台推送台风情况及辟谣信息50余篇。由于宣传及时到位，及时阻绝了不实消息。

In just a little more than three years Aqua Security has set its mark in the container security space. With its major new release of Aqua 3.5, the company has again raised the bar with serverless and container encryption upgrades and feature sets.

I sat down with the Aqua Enforcer himself, Rani Osnat, and “Boston” Andy Feit to discuss the details of this major release. Rani and Andy give us an inside peek.

As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

Alan Shimel:Hey everyone, it’s Alan Shimel, DevOps.com, and you’re listening to another DevOps Chat. Today’s chat is a little bit about cybersecurity, container security, Kubernetes and a major new release coming out of our friends at Aqua, Aqua Security. I’m happy to be joined with the dynamic duo of marketing at Aqua, Andy Feit and Rani Osnat. Andy, Rani, welcome.

Rani Osnat:Hi Alan, thank you.

Andy Feit:Hi Alan, good to talk to you.

Shimel:And just so people know, Andy, you’re joining us from Boston today. And Rani, you’re out in Israel. Is that correct?

Osnat:Right.

Shimel:Modern technology. We have a worldwide panel. But guys, the big news is, Aqua just announced version 3.5 of their platform suite of tools. And you know, Aqua’s not a company that every single new time there’s a new release, and the DevOps mantra, you can’t get too excited about any one release. Right? Because there’s always a next one and a next one and a next one. But this is one to get excited about, huh?

Feit:Absolutely.

Osnat:We certainly think so.

Shimel:So why should we be excited?

Feit:Rani, you want to take that one?

Osnat:Yeah, I’ll take this one. So, with every release we make, especially, and in the beginning of course everything’s new. But we’ve been in this space now for three years. Which is not a long time, but in this space it’s a very long time. And so now we’re at the point where we have a lot of large enterprise customers using our product. And we have a market that’s looking for innovation.

And with every new release we try to balance these factors of, you know, offering something new that the market wants. But at the same time ensuring that our enterprise customers can make use of our platform, as they themselves grow their cloud native container implementations. So there is a maturity factor here as well as an innovation factor.

And so on the innovation side, we’re introducing a few significant innovations. First and foremost, risk assessments for serverless functions. Which is a, you know, a kind of a sideways expansion for us into the serverless technology space, in addition to containers. Thinking that you know, what we see as, it’s basically the same teams and the same benefits that are gotten from containers people expect to get from serverless, it’s just another means to get the same end.

And so we want to provide our customers with all the controls they need to address any challenges they have around securing those technologies. And it doesn’t matter if they use containers or serverless or both, or any sort of mixed environment. We also added something that’s innovative in the space, which is container encryption, and we can talk about that.

And then on the side of enterprise scalability and ease of use, we’ve added quite a significant I would say rearchitecting of how we manage both administrative controls on our platforms and what users can do in terms of access. As well as the policy engine to make it a lot more scalable for multicloud, multiteam, multiapplication use.

Shimel:Got it. Got it. Andy, did Rani leave anything out you want to add?

Feit:No, I mean, those are the big pieces that are in the release. As he said. I mean, it’s very much being driven by our customer base and where they’re headed. And you know, in some aspects, it’s the technology elements. Like adding serverless. And in other aspects, it’s really about living with the solution. You know, as our customers, we now have customers that are we think the largest container deployments in the enterprise.

We have some very large users and span of different industries. As they look to roll out, they’re finding they have multiple teams working on these projects. And they need to implement different levels of security. And in many cases, they’re implementing that on different technology stacks. And some are using containers, some are using serverless environments.

And they may be using even different underlying providers of some of the infrastructure. Whether that’s tools for development or the cloud provider itself. And so we’re really, we’re becoming very heterogeneous in terms of what we need to support. And for our customers who, on the security side, are trying to look at that whole context and manage that whole context and have consistent policies, all our consistent reporting across all of them, and not be monitoring 17 different dashboards. It’s important that it be easy to do, to be able to see that whole network of activity. And that’s really what a lot of this release is about.

Shimel:So guys, one of the things that you mentioned, both of you actually mentioned, was the serverless piece. And this is something that we are, we’re hearing a lot about from our readers and from people we speak to. You know, how quickly, and we live in crazy times, right? So the whole container revolution, if you backed up on hypervisors. And now, how quickly serverless is you know, gaining a foothold and people are building around that type of infrastructure.

Osnat:Right.

Shimel:Let’s, just baseline, what are some of the security challenges that you guys are seeing around this?

Osnat:Right. So I’ll preamble that, you know, just add one more thing. There’s, you know serverless has been around almost as long as containers have, in terms of the, you know, its current incarnation of the use in the cloud. But, the use cases is quite different. And while it is gaining traction, the use cases are much more limited than containers. There’s a whole kind of religious war, you know, between the proponents of containers and the proponents of serverless. Personally I don’t believe it’s a zero sum game. I think that both are going to end up being used, and both are going to end up being used in hybrid architectures.

Shimel:Yeah, I don’t think it’s either or.

Osnat:Yeah, I know, but some people would like you to think it is. I don’t think it is. I think it’s both. And so we, but there are some fundamental differences between containers and serverless when it comes to security. First of all, most of the serverless workloads that happen today are cloud based and specific to a cloud provider, right? Mostly Amazon, because Amazon is the larger cloud provider in general, as well as in serverless specifically with Lambda.

But basically you run those functions and it’s quite cloud specific. That’s one area of difference. The other is of course that you know, these are very small single-function entities that can run for a fraction of a second. So when we talk about run time security for serverless, for example, there is a lot less to do there than you have with containers.

I found this following code while researching about AES encryption on the internet. In this code I found that the key and the iv are generated using hash function and uses sha256. I would like to know whether this method is safe for encryption of tex

I am working on a project where I need to encrypt/decrypt some data locally. I am using RNCryptor for the encryption and decryption process. To do that I need to use key, i don't want to define that key from app side like: NSString *password = @"Secr

I am using php's openssl to encrypt sensitive user data on my website. I have an ssl certificate to provide further encryption. But how do I keep the key secure? I have done some research and come up with these steps to follow- 1) Store it in another

I wish to be more efficient in generating a random key and a random IV for the encryption. But is it workable and safe to use the random key as the IV?You could but it would not be secure. The usual practice is to use a cryptographically secure rando

I need to decrypt a AES-256-EAX encrypted string from Java in Ruby. Ruby's built-in OpenSSL::Cipher provides functionality to decrypt AES-256-CBC, when I try to use AES-256-EAX, its throwing that the algorithm is not supported. Is there any library/g

I need to generate symmetrics keys with standard AES in ECB mode block and with PKCS5Padding, but I can't do it. During my searches, I only found functions to encrypt something with this conditions above. But I don't want this; I want to generate a s

This question is a continuation of my last one, regarding How to make Ruby AES-256-CBC and PHP MCRYPT_RIJNDAEL_128 play well together. I've got that working now, but I'm still struggling to go the other direction. The PHP generated cryptogram appears

I got the following requirements for the encryption for the API i am currently trying to access: PKCS7 padding method CBC encryption mode AES key size 256, block size 128 Everytime i submit to the API with the encryption, there seems to be something

I have been using the openssl function for encrypting data with AES-256-CBC in php. I have been able to encrypt it using an unique IV (by generating with openssl_random_pseudo_bytes)for each new encryption. But I am struggling with the idea of authen

Laravel 5.4: The only supported ciphers are AES-128-CBC and AES-256-CBC with the correct key lengths

It is Laravel 5.4 setup of my web app. one thing is happening repeatedly on page load. and because of that, I am not able to get data on my page. Runtime exception: The only supported ciphers are AES-128-CBC and AES-256-CBC with the correct key lengt

I am writing a secure file sharing application in Java. The general architecture looks like this: User wishes to encrypt a file for secure sharing between multiple users. The application generates a random UUID on the client and uses this as the AES

I'm generating data to send from a Ruby stack to a PHP stack. I'm using the OpenSSL::Cipher library on the Ruby side and the 'mcrypt' library in PHP. When I encrypt using 'aes-256-cbc' (256-bit block size) in Ruby I need to use MCRYPT_RIJNDAEL_128 (1

Using this article as a guide I was able to successfully replicate MySQL's aes-128-ecb in PHP: final class Encryption { // The key const KEY = '36F3D40A7A41A827968BE75A87D60950'; /** * Encrypt a string * * @access public * @static * @param string $st

A series of cross-site request forgery (CSRF) bugs found by security researcher Artem Moskowsky inSamsung’s website could allow potential attackers to take over user accounts completely.

Moskowsky told ZDNet that the three issues were reported to Samsung during this month and the company rewarded him with $13,300 through its bug bounty program.

As further detailed by the researcher, the threeCSRF security issues affected the account management system on Samsung's website and they allowed attackers to change a user's security questions, disabletwo-factor authentication, and change the vulnerable account's profile info.

Cross-site request forgery attacks allow bad actors to execute commands through a user's web browser via a web application the victim is currently logged in.

In the case of the XSRF bugs found byMoskowsky, attackers could change the security questions and answers of any account by persuadingthe targeted Samsung users to click on a maliciously crafted link.

Following a successful compromise of the Samsung account, the attacker could reset the password with the help of the new security question and then log into the user's profile with the new credentials.

The attack worked because the vulnerable Samsung web app did not correctly check the referrer header of the data requests made by the attackers to make sure that they were made from domains with the proper access.

Because the referrer header checks weren't performed correctly, any domain could have requested the current security questions of any account on Samsung'saccount management system leading to theCSRF vulnerability.

"Due to the vulnerabilities, it was possible to hack any account on account.samsung.com if the user goes to my page. The hacker could get access to all the Samsung user services, private user information, to the cloud," told Moskowsky to The Register .

编辑推荐: 本文来自于codeceo，本文详细介绍了TLS中可被配置的算法，会话恢复以及OCSP（在线证书状态协议） 等相关知识。

最近在学习https性能优化，虽然网上已经有许多的关于https性能优化的文章了，但还是想写下这篇文章，作为学习总结=^_^=，文中对于一些概念性或实现细节上的东西并不会展开，但会给出相应的引用，有些图片也来自网上资源。

章节规划：

认识SSL/TLS

算法选择

会话恢复

OCSP stapling

TLS 缓冲区优化

TLS false start

其他优化

认识SSL/TLS

SSL和TLS都是用于保障端到端之间连接的安全性。SSL最初是由Netscape开发的，后来为了使得该安全协议更加开放和自由，更名为TLS，并被标准化到RFC中，现在主流的是TLS 1.2版本。

从上图，可以看出SSL/TLS是介于应用层和传输层之间，并且分为握手层（Handshake Layer）和记录层（Record Layer）。

握手层：端与端之间协商密码套件、连接状态。

记录层：对数据的封装，数据交给传输层之前，会经过分片-压缩-认证-加密。

从TLS 1.2 RFC可以了解更多： https://www.ietf.org/rfc/rfc5246.txt

算法选择

TLS中可被配置的算法分类：

数字签名 ：RSA、DSA

流加密 ：RC4

分组加密 ：DES、AES

认证加密 ：GCM

公钥加密 ：RSA

消息认证码 ：SHA

密钥交换 ：Diffie Hellman

密码套件决定了会使用到的算法，例如执行openssl ciphers -v 'ALL' | grep ECDHE-RSA-AES128-GCM-SHA256：

ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD

表明该算法是在TLS 1.2中支持的，密钥交换采用ECDH（EC是指采用椭圆曲线的DH）,数字签名采用RSA，加密采用128位密钥长度的AESGCM，消息认证码采用AEAD（AEAD是一种新的加密形式，把加密和消息认证码结合到一起，而不是某个算法，例如使用AES并采用GCM模式加密，就能够为数据提供保密性、完整性的保障）。

如何理解完整性？

A 将明文M加密后为MC，发给B，B解密，得到明文。 如果此时有中间人C，将MC替换为CMC（虽然C不知道A怎么加密的，但这没关系），B将CMC解密，得到明文（那么B拿到的其实是错误的明文）。 所以需要引入消息认证码，B才能够判断收到的密文是否被篡改过。 这里你可能会问：那如果C同时伪造消息认证码呢？ 这个就得看MAC和加密是如何配合的了，详情可以查看认证加密中的Approaches to Authenticated Encryption章节。

在TLS握手和数据传输的不同阶段会采用相应的算法：

服务端身份验证：数字签名（RSA、ECDSA）

密钥交换：RSA/密钥交换算法（ECDH）

加密/解密：流加密（RC4）和分组加密（3DES/AES/AESGCM）

生成消息认证码：SHA/AEAD

不知是否有人发现并没有提到压缩算法，如果google下TLS压缩优化相关的内容，会发现没有，因为目前在TLS 1.2 RFC中，关于压缩方法的结构定义为enum { null(0), (255) } CompressionMethod;，即只有null方法（不进行压缩）。目前存在对TLS压缩的攻击： http://www.CodeSec.Net/articles/web/5636.html ，可能是基于此原因，TLS压缩目前只是个概念性的东西，没有被真正应用起来。

如何选择算法――安全性

通常加密算法的安全性依赖于密钥的长度，且不同加密算法，即使密钥长度相同，但提供的安全性也可能是不同的，相关资料： key size 。所以并没有一个标准的归一化方法去衡量所有的加密算法，但是有来自世界上各个组织/机构对不同类型算法安全性的评估，可以看下这个网站： https://www.keylength.com/

执行openssl ciphers -v 'ALL' | wc -l会发现有100+个密码套件（不同openssl版本提供的密码套件有点差异），然而，实际只会使用到其中一部分，因为openssl提供的不少算法是不安全的，需要排除掉。

执行openssl ciphers -v 'HIGH MEDIUM !aNULL !eNULL !LOW !MD5 !EXP !DSS !PSK !SRP !CAMELLIA !IDEA !SEED !RC4' | wc -l，发现只剩下50+个密码套件。

筛选后剩下的密码套件还是挺多的，一个个做性能测试的话，会GG的= =。其实可以根据需要支持的客户端，再筛选出主流的密码套件。网址： https://www.ssllabs.com/ssltest/clients.html ，提供了绝大部分客户端对TLS的支持情况，点击相应的User agent可以查看到其支持的密码套件，并且各套件的安全性也被标注出来了。

网址： https://www.ssllabs.com/ssltest/ ，可以用于测试服务器的SSL配置情况，并会给出得分，如下图google的得分为A：

如何选择算法――性能

以下性能测试都是选取主流的算法进行。

数字签名：ECDSA vs RSA

需要先分别生成采用ECDSA和RSA的签名证书。

生成ECDSA自签名的证书：

openssl ecparam -name prime256v1 -genkey -out ec_key.pem

openssl req -new -x509 -key ec_key.pem -out cert.pem -days 365

-param_enc参数使用默认的named_curve就可以了，如果使用explicit，会发现生成的证书nginx能配置成功，但客户端连接时会出现handshake error。

生成RSA签名的证书：

openssl req -newkey rsa:2048 -nodes -keyout rsa_key.pem -x509 -days 365 -out cert.pem

执行openssl speed rsa2048 ecdsap256测试下：

sign verify sign/s verify/s

rsa 2048 bits 0.000834s 0.000024s 1198.9 41031.9

sign verify sign/s verify/s

256 bit ecdsa (nistp256) 0.0000s 0.0001s 21302.5 9728.5

可以看到签名性能ECDSA > RSA，而验证性能RSA > ECDSA。

测试环境：

服务端：1台虚拟机CentOS 4核 openresty 2个worker

客户端：4台虚拟机CentOS 4/2/2/2核（手头只有这些虚拟机= =）， 用shell脚本模拟并发的ab -c 800 -n 800（并发的ab实例数=2*CPU_NUM），使用time命令获取消耗的时间

测试页面562字节，目标是测试数字签名的性能，所以页面小点，避免加密/解密、数据传输占用太多时间

多台客户端如何同时启动？ctrl+tab，命令+回车……

为什么不用jmeter？我用了1Master3Slave的jmeter分布式压测发现，jmeter对于在该场景（CPU bound）下的性能测试不行，服务端压力上不去

在相同的请求量下，RSA签名会使服务端CPU占用更高，所以这次测试需要在两种签名的压测下，服务端CPU都保持在90%以上（不然的话，对ECDSA就不公平了）。

为何openresty是2个worker？因为开4个的话，ECDSA的压测没法使openresty4个worker的CPU消耗达到90%

ECDHE-ECDSA-AES128-GCM-SHA256，服务端CPU占比90%，结果：

ECDHE-RSA-AES128-GCM-SHA256，服务端CPU占比100%，结果：

从表格中的数据可以看出ECDSA的性能要比RSA好点，这里ECDSA的测试尚未压榨完服务端呢。从openssl speed的结果也可以看出ECDSA的签名性能是要远超过RSA的，而且签名是在服务端做的，所以面对海量的客户端，服务端应该选择使用ECDSA。

密钥交换：RSA vs ECDHE

测试环境同上，但只使用了4/2核两台客户端机器发请求。证书使用的是生成的RSA证书，ECDSA证书能用到的密钥交换算法只能是ECDHE。

AES256-GCM-SHA384，服务端CPU占比100%，结果：

ECDHE-RSA-AES256-GCM-SHA384，服务端CPU占比100%，结果：

从表格中的数据可以看出ECDHE与RSA的性能差不多。ECDHE比RSA要多了一次端到端的传输，还会用到RSA对DH参数进行签名和验证；而RSA密钥交换则会使用到RSA的加密/解密，具体可看如下CloudFlare的两张图

ECDHE支持 前向保密（Forward Secrecy） ，简单理解：中间人可以保存下来客户端和服务端之间的所有通信数据，如果使用RSA握手，那么未来某一天，中间人如果获取到了服务端的私钥，就可以解密所有之前采集的通信数据了；如果采用ECDHE握手的话，就可以避免这个问题。而且使用ECDHE握手的话，还有可能开启TLS false start的特性（下文中会提到）。

RSA握手：

ECDHE握手：

所以密钥交换算法ECDHE会更好些。

对称加密：AES256-GCM vs AES256 vs AES128-GCM vs 3DES

测试环境同上，但只使用了4核一台客户端机器发请求，ab参数为ab -n 2000 -c 10，ab实例4个，测试页面153K。因为是要压测对应用层数据的加密解密性能，所以连接数少，但每个连接的请求数多。

ECDHE-RSA-AES256-GCM-SHA384，服务端CPU占比94%，结果：

ECDHE-RSA-AES256-SHA384，服务端CPU占比98%，结果：

ECDHE-RSA-AES128-GCM-SHA256，服务端CPU占比92%，结果：

DES-CBC3-SHA，服务端CPU占比100%，结果（太慢了，就测了两个=。=）：

从表格中的数据可以看出AES128GCM > AES256GCM > AES256 > 3DES。

消息认证码：SHA256 vs SHA1 vs AEAD

测试环境同上。

AES256-SHA256，服务端CPU占比100%，结果：

AES256-SHA，服务端CPU占比98%，结果：

AES256-GCM-SHA384，服务端CPU占比95%，结果：

从结果中可以看出AES256-GCM-SHA384 > AES256-SHA > AES256-SHA256。

会话恢复

Session Cache

客户端希望恢复先前的session，或者复制一个存在的session，可以在ClientHello中带上Session ID，如果服务端能够在它的Session Cache中找到相应的Session ID的session-state（存储协商好的密码套件等信息），并且愿意使用该Session ID重建连接，那么服务端会发送一个带有相同Session ID的ServerHello。

目前Nginx 只支持单机Session Cache，Openresty 支持分布式Session Cache，但处于实验阶段。

Session Ticket

Session Cache需要服务端缓存Session相关的信息，对服务端存在存取压力，而且还有分布式Session Cache问题。 对于支持Session Ticket的客户端，服务端可以通过某种机制将session-state加密后作为ticket发给客户端。客户端凭借该ticket就可以恢复先前的会话了。

类似于HTTP中用Json Web TOken作为cookie-session的另一种选择。

OCSP（在线证书状态协议） stapling

当客户端在握手环节接受到服务端的证书时，除了对证书进行签名验证，还需要知道证书是否被吊销了，那么需要向证书中指定的OCSP url发送OCSP查询请求。

对于同一份服务端证书，如果每个客户端都自己去查询一次证书状态就浪费了。所以，OCSP stapling就是为了解决这一问题，由服务端查询到证书状态（通常会缓存一段时间），并返回给客户端（客户端会在本地校验这个证书状态是否真实）。

在nginx的配置中，可以选择性的配置是否对OCSP response做校验，防止将非法的证书状态发送给客户端。如果设置了校验，ssl_trusted_certificate参数需要为包含所有中间证书+根证书的文件。

如下图是对nginx请求OCSP Server的抓包，可以看到发了个http的ocsp请求：

下图是对nginx在发送证书给客户端时，带上的证书状态的抓包：

TLS缓冲区调优

nginx默认的ssl_buffer_size是16K（TLS Record Layer最大的分片），即一个TLS Record的大小，如果HTTP的数据是160K，那么就会被拆分为10个TLS Record（每个TLS Record会被TCP层拆分为多个TCP包传输）发送给客户端。

如果TLS Record Size过大的话，拆分的TCP包也会较多，传输时，如果出现TCP丢包，整个TLS Record到达客户端的时间就会加长，客户端必须等待完整的TLS Record收到才能进行解密。

如果TLS Record Size小一些的话，TCP丢包影响的TLS Record占比就会小很多，到达客户端的TLS Record就会多些，客户端干等着的时间就相对少了。但是，TLS Record Head的负载就增加了，可能还会降低连接的吞吐量。

假设ssl_buffer_size设置为1460byte：

通常，在TCP慢启动的过程中，TLS Record Size小点好，因为这个时候TCP连接的拥塞窗口cwnd较小，TCP连接吞吐量也小。而在TCP连接结束慢启动之后，TLS Record Size就可以增大一些了，因为这个时候吞吐量上来了。所以更希望能够动态的调整nginx中ssl_buffer_size的大小，目前官方nginx还不支持，不过cloudflare为nginx打了个patch，以支持动态的调整TLS Record Size： Optimizing TLS over TCP to reduce latency

TLS False Start

某一端在发送 Change Cipher Spec、Finished 之后，可以立即发送应用数据，无需等待另一端的 Change Cipher Spec、Finished 。这样，应用数据的发送实际上并未等到握手全部完成，从而节省出一个RTT时间。

完整握手时，Client Side False Start：

简短握手时，Server Side False Start：

可以看下这篇文章：TLS False Start究竟是如何加速网站的 和 Transport Layer Security (TLS) False Start

RFC7918中并没有对Server Side False Start进行定义（其之前的草案中就有提到，draft-bmoeller-tls-falsestart-00/01），文中的说明：However, if the server sends application data first, the abbreviated handshake adds two round-trip times, and this could be reduced to just one added round-trip time by doing a server-side False Start. There is little need for this in practice, so this document does not consider server-side False Starts further.

可能是在之前的HTTP 1场景下，对Server Side False Start的需求并不强烈，或者说实践不多（当然其他应用层协议可能会有，例如websocket）。

Client Side False Start需要的条件：

客户端和服务端都需要支持NPN/ALPN（浏览器要求）

需要采用支持前向保密的密码套件，即使用ECDHE进行密钥交换（RFC7918中有规定）

其他优化

TCP优化，毕竟SSL数据也是基于TCP进行传输的

证书优化，采用ECDSA证书、服务器发送给客户端的证书链包含所有中间证书

硬件配置优化，例如使用SSL加速器

总结

本文是个人近段时间学习到的关于HTTPS性能优化的总结。

推荐的密码套件列表：

<table width="60%" border="0" align="center" cellpadding="7" cellspacing="1" bgcolor="#CCCCCC" class="content" style="text-indent: 0em;">

<tr bgcolor="#FFFFFF">

<td height="25" bgcolor="#f5f5f5"> Hello World!</td>

</tr>

</table>

其他额外的密码套件，比如需要支持IE6，可以放在密码套件列表末尾。

自己写了个go程序用于检测密码套件列表支持/不支持的客户端： sslciphersuitescheck

Imagine if each alert you received was actually usable and could tell a complete, linked, relevant story that’s exactly what SentinelOne did in the MITRE ATT&CK simulation. We built our product to be bold and different. In MITRE terms, each SentinelOne alert curated 37 commands. Alert fatigue ends here.

Don’t be fooled: Missed real-time alerts yield attacker dwell time which increases risk and damage. Minimize real-time misses by mastering detection with a performant product versus a delayed service.

Missed real-time alerts yield attacker dwell time which increases risk and damage

It was 1996; Gary Kasparov, the world’s greatest chess grandmaster lost to IBM’s Deep Blue computer. In the EDR space, a similar watershed moment happened a few weeks ago: for the first time, in a third party test, SentinelOne proved that autonomous technology is independently and efficiently capable of the most nuanced EDR in real-time.

In MITRE’s recent ATT&CK Evaluation, the SentinelOne agent detected, tracked, and linked the context of all APT attacks with ONE autonomous agent in real-time without delayed cloud or human powered resources. Other EDR vendors have “store and analyze” dependencies, making them reliant on skilled people, cloud services, and required service modules. SentinelOne’s patented prevention capabilities stop attacks before and during execution at the source; in addition, all analysis is done on-agent, by the agent, in real-time, providing maximum EDR detection, visibility, and control.

The MITRE test consisted of two multi-staged attacks using the Cobalt Strike and PowerShell Empire frameworks. The attacks used a total of three devices. SentinelOne showed four behavioral alerts in the console: this is by design. Each alert represents the complete story of an attack in real-time on the device it was detected on, with all of the information mapped in the alert details. Each alert was generated during the very first phase of each attack. Below is the SentinelOne console used for the test:

Under the alerts, the autonomous agent automatically captured and correctly mapped over 205 observed actions in real-time. If performed as standalone actions, SentinelOne alerts on each action the brilliance is how SentinelOne recognized and autonomously mapped the orchestrated attack.

In the case of the test, SentinelOne doesn’t spawn multiple (unnecessary) alerts for the same attack even if it observes other alertable or enriching behavior in the attack as it progresses. Instead, SentinelOne maps the additional observed actions into the attack story, making a complete story which is much easier for SOC analysts to understand. In total, the autonomous agent mapped over 34,000 observed actions including C2 to their correct attack story lines.

Check out the real screenshots showing the attack story lines from the attack commands:

Delayed Detections

According to MITRE, this is a negative alert modifier for detections.

Delayed detections are detections that happened after commands had completed and required an MDR service to find them after the fact. The time between when the command was completed and the alert showed in a console is added (and unnecessary) dwell time for the attacker to exploit an environment. According to MITRE testing guidelines, delayed detections were permitted to appear up to 24 hours following the completion of a command. In the real world, delayed detections can appear in hours, days, or sometimes even longer.

A real-life example : A person breaks into your house and steals a bunch of stuff. This is recorded on a video surveillance system which is reviewed hours later when the break in is discovered. The delayed detection of the break in lets you know what happened on camera, hours later, but not what happened off camera. Furthermore, the damage is done before it was even detected. And you must ask yourself: is the criminal still running around your house?

A valid way of looking at MITRE ATT&CK evaluation results is to focus on real-time data . Below is an example of the data when viewed from combining delayed and missed alerts and telemetry as reported by MITRE.

A performant EDR solution is one that doesn’t increase attacker dwell time with missed or delayed alerts.

According to MITRE, “tainted” is a positive modifier for telemetry:

“Tainted” detections links other commands or actions to a previous alert. This linking is something that the SOC analyst doesn’t have to spend time performing. Some vendors had to manually perform queries after the fact to the infected endpoints to obtain this data. In the case of SentinelOne, the “tainted” telemetry was mapped in real-time to the correct context of each attack.