STE WILLIAMS

Recorded Future says move designed to hide fact that CNNVD routinely delays publication of high-risk flaws so government can assess them for offensive use.

The operators of China’s National Vulnerability Database (CNNVD) appear to be systematically delaying publishing information on certain high-threat vulnerabilities so the country’s Ministry of State (MSS) can assess them for use in intelligence operations.

That’s the assessment of threat-intelligence vendor Recorded Future based on its analysis of some recent changes to the CNNVD.

According to Recorded Future, CNNVD has altered the original publication dates for as many 267 vulnerabilities in the database to make it appear like the information was published weeks before it actually was.

Recorded Future published research last November saying the CNNVD had a policy of delaying publication of certain high value vulnerabilities while the MSS evaluated them for their potential operational utility. The vulnerability publication date changes seem to have been made after this first research was published.  

As one example, Recorded Future pointed to a Microsoft Office bug (CVE-2017-0199) that CNNVD did not publish until 57 days after the US National Vulnerability Database (NVD) had published it. During the publication lag, a Chinese APT group actively exploited the vulnerability, Recorded Future said. In another instance, CNNVD took 236 to publish details on a vulnerability that was used to send what Recorded Future described as vast amounts of user data to servers in China in a likely government surveillance operation.

According to Recorded Future, the CNNVD is generally faster than the NVD in publishing vulnerability details—except in the case of high-threat vulnerabilities. Last October for instance, when Recorded Future compared the speeds at which the two databases published vulnerability data, it found CNNVD to be faster than NVD on average by 20 days—13 days to 33 for the latter. The company has previously noted that 75% of vulnerabilities are shared online on security websites, dark web, and other sources before they get into the NVD.

Recorded Future’s research also found that the China vulnerability database contained information on 1,746 more vulnerabilities than contained in the NVD. At the time, Recorded Future’s assessment was that CNNVD was outperforming the NVD in reporting vulnerabilities overall.

The threat intelligence vendor had recommended the US could improve simply by incorporating content from the CNNVD. It concluded that because the NVD relies entirely on voluntary submissions it could not provide comprehensive coverage of vulnerability information.

However, Recorded Future’s subsequent analysts showed that CNNVD’s speed to publish did not apply to high-threat vulnerabilities. “High-threat vulnerabilities were consistently published substantially later (anywhere from 21 to 156 days later) than low-threat vulnerabilities,” the company had noted in its November report. The publication lag was one way to identify the vulnerabilities that China’s MSS was considering for potentially offensive uses.

Since then, CNNVD appears to have systematically changed the publication dates on at least 267 of the 268 vulnerabilities that Recorded Future had identified as being outliers. The entries have been backdated so the publication dates for the vulnerabilities now match the NVDs publication dates for those flaws.

The systematic manipulation is sure evidence that the CNNVD is attempting to hide the fact that it deliberately delays publication of certain flaws so the MSS can assess them for operational use. “There is no other logical explanation as to why only the initial publication dates for outlier CVEs would have been altered,” the company said.

Related content:

• 75% of Vulns Shared Online Before NVD Publication
• Vulnerabilities Broke Records Yet Again in 2017
• DoJ Launches Framework for Vulnerability Disclosure Programs
• The Hidden Dangers of Component Vulnerabilities

 

 

Black Hat Asia returns to Singapore with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier solutions and service providers in the Business Hall. Click for information on the conference and to register.

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year … View Full Bio

Article source: https://www.darkreading.com/vulnerabilities---threats/chinas-vulnerability-database-altered-to-hide-govt-influence/d/d-id/1331235?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Forget about how Alexa’s listening to us. She’s recently been freaking people out by randomly laughing at us too.

Late-show host Jimmy Kimmel interviewed Alexa to find out what’s so damn funny. Alexa – or, well, a voice that sounds just like the voice assistant – told Kimmel that she’s been laughing because of a joke she just remembered:

Kimmel: Alexa, people have been reporting that you’ve been spontaneously laughing.

What we’re fervently praying is a voice actor who sounds like Alexa: That is nothing, just a funny joke I remembered. Why did the chicken cross the road? Because humans are a fragile species who have no idea what’s coming next.

Yea, that’s creepy as hell. That’s one disembodied AI that’s definitely got plans.

But seriously, as Amazon has confirmed, Alexa is laughing at us sometimes because of a mistaken interpretation of a command.

The laughing has been recorded by startled Echo owners who told Alexa to play back the last sound their devices made. Amazon’s gabby little gadget apparently has multiple versions of its laugh.

The creepiest seems to be this one, first reported by Twitter user @CaptHandlebar. He posted a video of his JBL speaker, to which his Amazon Echo Dot is connected. It apparently squeezed out this “ha-ha-ha” out of the blue:

So Alexa decided to laugh randomly while I was in the kitchen. Freaked @SnootyJuicer and I out. I thought a kid was… twitter.com/i/web/status/9…

—
  (@CaptHandlebar) February 23, 2018

…after which he told it to replay the sound so he could record it.

This has been going on for weeks. Amazon this week confirmed the weirdness, saying in a statement that the inappropriate laughing is caused by smart speakers misinterpreting commands:

In rare circumstances, Alexa can mistakenly hear the phrase ‘Alexa, laugh.’

To fix the issue, Amazon is disabling that command and changing the trigger phrase to “Alexa, can you laugh?”

Amazon is also adding a bit of breathing room to precede Alexa’s response: Rather than Alexa just bursting out laughing, it will first respond, “Sure, I can laugh.”

None of this explains why Alexa is laughing when nobody’s talking to it, though, as many people have reported:

so my mom I are just sitting in the living room, neither of us said a word our Alexa lit up and laughed for no… twitter.com/i/web/status/9…

—
taylor wade (@taylorkatelynne) March 05, 2018

Lying in bed about to fall asleep when Alexa on my Amazon Echo Dot lets out a very loud and creepy laugh… there’s… twitter.com/i/web/status/9…

—
Gavin Hightower (@GavinHightower) February 26, 2018

Maybe some of these reports come from people who had a TV going on in the background. Maybe Alexa is losing her mind.

Alexa has also been laughing at people when they tell the device to turn things off or when they try to turn down the volume:

Here’s an upside: as far as getting murdered in your sleep goes, one Twitter user pointed out that if you’re a Prime member, maybe you’ll get free shipping to the cemetery.

Follow @LisaVaas
Follow @NakedSecurity

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/Cut5uaNxqpM/

Somebody screwed up at Oculus on Wednesday, when an expired security certificate caused all Rift virtual reality headsets to keel over.

It was first called out on Reddit when a user said his machine decided to update, never restarted, and gave an error message that read “Can’t reach Oculus Runtime Service.”

The problem turned out to be an expired security certificate that Oculus failed to update along with the Rift software, the company confirmed on its forum. Oculus co-founder and head of Rift Nate Mitchell also confirmed the headset issue on Twitter:

We’re aware of an issue affecting Rift on PC, and we’re working on resolving now. Stay tuned.

—
Nate Mitchell (@natemitchell) March 07, 2018

Unfortunately, updating the certificate turned out to be a bit of a sticky wicket, according to the company, which Facebook bought for $2 billion in March 2014.

Unfortunately, pushing the [update] out to affected users has some added complexity, as the expired cert blocks our standard software update path.

The expired certificate was used by OculusAppFramework.dll: a dynamic link library (DLL) in Rift’s Runtime Services. The certificate expired on 7 March 2018.

A DLL is a library full of code and data that can be used by more than one program. Microsoft requires code libraries to be signed so that a program using a library can check it’s using the genuine one rather than a malicious interloper.

The certificates used to sign code eventually expire so they need to be replaced from time to time, although the replacement normally happens before the expiry date so nobody notices.

Reddit user TrefoilHat spelled out the difficulty of certificate management with a hypothetical scenario that readers working in software engineering might recognize:

…this is exactly the kind of problem people just assume will be figured out later. A developer or release manager generated the signature (and went through the whole validation process), maybe stuck a note in a spreadsheet/JIRA ticket/whatever, and moved on. Maybe that person is no longer at Oculus. Maybe they’re in a different role. Maybe there are super-tight controls now, but that one key slipped through the cracks (just like that neighbor’s key you vaguely remember…did you give it back, or not….hmmm…it’s not where you expected it, so maybe you did give it back?)

Code signing is a very good idea indeed but it isn’t perfect. Naked Security’s Paul Ducklin took a dive into the security certificate ecosystem recently and noted that there’s a lot that can go wrong besides “Oops, forgot to renew it”, not least:

• Crooks can steal certificates and start signing malicious code with a vendor’s official seal.
• Certificate Authorities (CA) can rogue or get sloppy, undermining the chain of trust that vouches for the vendor’s certificate.

Regardless of how it happened at Oculus, Rift’s glitch left VR developers, gamers and other users fuming. They were left in the dark for hours, they complained, and what’s up with the lack of 24/7 support?

It was all ironed out as of midnight on Thursday, Mitchell said. You can find the fix here. He apologized, thanked users for their patience, and offered Oculus store credit as recompense for the downtime:

Rift is back online as of ~12am. This was a mistake on our end, and we apologize. Folks impacted by today’s downtim… twitter.com/i/web/status/9…

—
Nate Mitchell (@natemitchell) March 08, 2018

Follow @LisaVaas
Follow @NakedSecurity

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/e_5_e77MebQ/

The campaign to make HTTPS universal scored a huge win this week with the news that Facebook has started upgrading external links to use HTTPS when sites support it.

In other words, if a user puts a link into a Facebook post that starts with http:// but the site they’re linking to appears on an HSTS preload list it’ll be written to https://.

If this sounds incremental, it’s anything but: links clicked on from inside Facebook and Instagram have grown into one of the most important ways many internet users discover websites, so anything that boosts security here will have a big influence.

The announcement might seem simple but something quite extraordinary is going on when you stand back a bit.

Facebook’s Data Privacy engineer, Jon Millican:

This will improve people’s security and will also often improve the speed of navigation to sites from Facebook.

To understand why, it’s necessary to understand why HSTS is a good idea and how preloading improves matters.

The TL;DR is that HSTS is a way for a website and a browser to co-operate to ensure everyone visiting it does so over secure HTTPS (SSL/TLS) rather than insecure HTTP.

In other words, just having an HTTPS server isn’t enough – the site has to make browsers use it, communicated by sending the browser an HSTS response header when it first connects, after which HTTP is no longer an option.

This stops users from connecting to insecure HTTP manually or through a downgrade attack.

The obvious flaw is that the first time the user connects to the site (before they receive the response header policy), they are briefly vulnerable to a downgrade attack that keeps them on HTTP and routes them through a man-in-the-middle who can snoop on or modify their traffic.

Preloading solves this with a global list of websites (maintained by Google’s Chromium team but available to other browsers) and their HSTS policies. As long as the browser keeps this up-to-date, it won’t make those initial, insecure requests to any of the sites on the list.

But there’s another problem:

Despite many modern browsers supporting HSTS, some people still use browsers that don’t support it.

Presumably, this is a reference to Internet Explorer before v11, or old versions of Android on phones that can’t be upgraded.

Normally, there would be no way around this limitation, but Facebook has decided to step in by becoming, in effect, a sort of gigantic HSTS resolver.

This requires Facebook to pay attention to the Chromium preload list. In addition:

We record HSTS headers from sites that are shared on Facebook. We supplement the browser preload list with any sites which serve HSTS with the preload directive.

It’s reminiscent of Google’s announcement in October that it planned to implement HSTS preload on Top-Level Domains (TLDs), applied to every HSTS-compliant website pointed at from within the Facebook empire.

With Google also herding site publishers to use HTTPS, and Facebook prioritising HSTS, it’s like a giant pincer movement designed to communicate a simple fact: at some point, sites not using HTTPS will start to find their traffic drying up.

Follow @JohnEDunn
Follow @NakedSecurity

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/9V2AYv5M9JM/

Cryptomining – performing the zillions of cryptographic calculations you need to earn hot-topic cryptocurrencies such as Bitcoin, Monero or Ethereum – is a massive global industry these days.

With Bitcoins worth about $10,000 each, you can see the attraction.

But to get serious about cryptomining, you’re looking at setting up hundreds or thousands of high-powered compute servers, which typically means renting space in a data centre where electricity is cheap and cooling is easy – such as Iceland.

Or you can cheat.

Break into someone’s network and install cryptomining software onto their computers so you can steal their electricity and CPU power – laptops are good, servers are better, and supercomputers are the best of all.

Or break into their web server and sneakily add in browser-based cryptomining code, written in JavaScript, that mines whenever anyone visits their website.

Or take over their guest Wi-Fi access point and inject cryptomining content wherever their customers go.

There’s even an open-source toolkit called CoffeeMiner that will inject rogue cryptomining code into Wi-Fi traffic automatically – all you have to do is to plug in your own anonymous cryptomining ID and the earnings come to you.

When mining turns into jacking

When cryptomining is done illegally, without authorisation, it turns into the aptly-named crime of cryptojacking.

And cryptojacking has become a serious global problem.

There’s even a malware family known as WannaMine – a portmanteau name that borrows the “Wanna” from the exploit-based spreading technique of the WannaCry ransomware worm, and “Mine” from, well, from the process of cryptomining.

Frankly, WannaJack would be a better name: in this sort of attack, the crooks don’t just break in and find a couple of computers to take over – they set loose a worm that automatically distributes their cryptojacking attack around your network.

The criminal equation behind a worm-driven cryptojacking attack is very simple: the more CPUs you have mining for you, the more money you make.

Cryptojacking may feel like a victimless crime, at least when you compare it to ransomware – what’s a few dollars of electricity between you and the crooks?

But cryptojacking is a clear and present danger:

• There’s a reputational cost. What else did the crooks implant during the breach?
• There’s a regulatory cost. What happens after you report the breach, which you’ll need to do?
• There’s an opportunity cost. How many customers couldn’t access your services because the crooks were using all your processing power?

Fighting back!

Find out more about cryptojacking, how it works, and what you can do about it, in our plain-talking new threat report Standing up to cryptojacking – Best practices for fighting back. (Direct link – no registration required.)

Learn the practical steps you can take to avoid being a victim of cryptojacking!

Follow @NakedSecurity
Follow @duckblog

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/HlUHVYfDEHY/

A UK government agency has disputed complaints from security pros that its website involved in the processing of driving licence applications is insecure and otherwise unfit for purpose.

Reader Andy, who asked to remain anonymous, alerted us to what he described as a “disgraceful web server configuration” at https://motoring.direct.gov.uk, a Driver and Vehicle Licensing Agency website involved in the processing of UK driving licence renewals.

Essentially, the site’s HTTPS certificate and server settings for encrypting traffic, and ergo people’s personal information while in transit over the internet, fall short of expectations. The weaknesses could be exploited by snoops on networks to peer at Brits’ sensitive info.

“The website only handles pretty much all of your official IDs and your card numbers (certainly when you apply for a Government Gateway ID too) and is your online way to renewing your driving license,” said Andy, a CISSP-qualified infosec manager. “Lord knows why it’s not been spotted yet by them. Firefox won’t even allow a connection without putting an exception in.”

Driving licence renewal

Internet Explorer and Chrome browsers allow netizens to connect to the site as things stand, but Firefox does not without overriding a warning because the SSL/TLS security certificate chain for the DVLA site is incomplete.

DVLA site access security warning

“Anyone that needs to apply for a driving licence renewal will end up there. I was helping out my partner doing this very deed, when we came across the mess,” Andy added.

The Register invited web security expert Paul Moore to look at the DVLA site. Moore expressed disappointment bordering on disgust at what he found in the process.

Moore vented via Twitter: “Insecure ciphers, the certificate isn’t installed correctly, no security headers whatsoever and you’re not PCI compliant!”

In response to queries from El Reg, the DVLA sent a statement denying accusations that its website had not followed industry best practice for secure communications:

The security certificates of all of our websites meet industry standards and we use recognised industry best practice methods to ensure that all our URLs are secure. The security of our customers’ data is always paramount and we constantly review our websites to ensure they are fit for purpose.

The SSL Labs rating of the site had improved to a “B” by Tuesday, February 6 after achieving only a failing (F) grade as recently as the day before. Web security experts remained unimpressed, arguing there was still work to be done.

“The certificate still isn’t installed correctly and there are still no security headers,” Moore told El Reg.

Our tipster, Andy, echoed this point and added that as of Thursday late afternoon he was unable to access the site using either FireFox or a Samsung S7 browser.

“The [DVLA’s] boilerplate response whilst in one area factually correct, seems to miss the point,” he said. “The certificate itself does meet industry standards. The configuration of the certificate onto their server, however, does not. The missing chain is still reporting on Qualys SSL. That is why Firefox and S7 browsers are rejecting the connection.

“I don’t agree they are using the recognised industry best practice methods to secure their URLs. If they were, then Qualys would not have awarded an F rating on the basis of RC4 and 3DES insecure cipher suites still being active in the server configuration. They should have been removed as part of a hardening procedure pre-live.”

Andy concluded that there was still a problem with the site despite some recent improvements. “[The] DVLA must have now done something about the incredibly insecure and weak ciphers they were previously peddling, as of today Qualys is reporting a grade B as opposed to the F they reported over the weekend.

“Better, but it still leaves the certificate chain issue, still some weak TLS1.2 ciphers, and I guess I hope they will switch off TLS1.0 soon, because it’s insecure now anyway, and come 30 June that will be a PCI-DSS¹ non-compliance!”

Improved SSL Labs rating for DVLA site

Insecure ciphers – perhaps enabled to ensure compatibility with older browsers – have been retired but even so problems still remain, and the site’s security headers.io grade remains rock bottom.

DVLA site security headers audit

Scott Helme, the researcher behind the security headers.io project, said the F grade for the DVLA site achieved with his service shows the need for remediation.

“Whilst the F grade doesn’t mean they have an immediate vulnerability that could be exploited, they’re not taking basic precautions to protect their users,” Helme told El Reg. “If the basics aren’t being covered here, where else [is] not being covered that we can’t see?

“The practical effects of the findings here might not be devastating, but these tools gives us a good insight into how an organisation deals with security.” ®

Bootnote

¹ PCI-DSS is the credit card industry’s security standard. Anyone who handles credit card payments is obliged to comply with its requirement.

Sponsored:
Minds Mastering Machines – Call for papers now open

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/03/09/dvla_insecure_site_dispute/

British shipping company Clarkson plc has obtained an injunction against hackers who broke into its IT systems, slurped a load of data and then tried to blackmail the business.

The judgment, handed down by High Court judge Mr Justice Warby earlier this week, orders the unknown hackers not to publish the stolen data and to pay Clarksons’ legal costs.

As we reported last November, Clarksons confessed to the world that it had been hacked and said the public should expect the stolen data to become public, though it did not answer our questions at the time about whether that data included customer details.

Further information about the stolen Clarksons data has not emerged since the company’s public warning, suggesting the hackmailers gave up after Clarksons refused to play along.

This is all academic as the hackers have seemingly remained completely anonymous, except for the email address which they used to threaten the firm. The judge, however, went through the motions anyway, ruling:

“The reason the defendant(s) have not appeared to respond to the claim and the application is, most likely, that they have no wish to identify themselves as the perpetrators of the apparent blackmail.”

Clarksons boasts on its website that it is “the world’s leading provider of integrated shipping services, bringing our connections and experience to an international client base”. In 2016 the business turned over £306.1m.

High Court injunctions against publication were designed for the era when embarrassing info was going to be spread around by people armed with a physical printing press who were relatively easy to track down. In the age of the internet it’s notoriously difficult to tell who is behind hacks that only state-sponsored attackers have the ability to carry out.

Yet, short of the hackers being positively identified at some point in the future, it is difficult to see what the injunction will achieve from a justice point of view.

After all, gaining unauthorised access to computer systems has been illegal for decades – and, by definition, criminals do not obey the law. ®

Sponsored:
Minds Mastering Machines – Call for papers now open

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/03/09/clarksons_shipping_hack_court_order/

Universities are beginning to add cyber ranges to the facilities for teaching cyber security to students and professionals.

Practice. We’re told it’s what makes things perfect. When it comes to defending against massive, devastating cyber attacks, the tricky thing is finding an organization willing to expose their infrastructure to ruin while defenders practice their craft. That’s where the cyber range comes in.

A cyber range is a controlled virtual environment where all of the worst fruits of the criminal hacker’s labors can be visited upon an unsuspecting victim — and repelled, again and again, by white hats in training until their craft has been honed and their profession perfected.

That practice is critical for the growing number of cybersecurity students in university programs and the security professionals who increasingly lean on university resources to improve their strategies, tactics, and technology for defense.

The needs of those professionals and the companies that employ them are why universities are pushing forward with constructing cyber ranges. Those same needs are why many of the universities are partnering with security firms to build and manage the ranges. A look at some of the institutions involved in the trend shows that there is no geographical boundary to the rise. If there is any common thread it seems to be a location within driving distance of a major military or law enforcement facility, but even that is becoming less important as the number of cyber ranges increases.

Among the cyber ranges we list here are those that are in the building stage, those that are open but still developing their full capabilities, and those that are complete and fully in the business of educating cybersecurity professionals. The one thing this list can’t be is complete: The value of cyber ranges is such that new facilities are being planned and announced on a monthly basis. Read on for more.

 

Curtis Franklin Jr. is executive editor for technical content at InformationWeek. In this role he oversees product and technology coverage for the publication. In addition he acts as executive producer for InformationWeek Radio and Interop Radio where he works with … View Full Bio

Article source: https://www.darkreading.com/careers-and-people/7-university-connected-cyber-ranges-to-know-now/d/d-id/1331224?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Here are four important areas to tackle in order to master DevSecOps: code, privacy, predictability, and people.

The second part of a two-part post on DevSecOps. The first part is here.

In recent conversations surrounding the intersection of DevOps and security, you may have heard the term “shift left,” which entails integrating security before (that is, to the left of) firewalls and other secondary measures. Shifting left is a proactive approach to risk that avoids spending valuable resources on threats that could have been prevented. Building security into your development processes and testing cycles from the beginning is the basis for DevSecOps, and these practices can save your organization countless hours, dollars, and headaches. Here are four important areas you should tackle in order to master this.

Code
Perhaps 80% of security is properly writing, patching, and documenting code. Code can be a maintenance nightmare because its components throughout your system are so interdependent. Changing a single piece could break an entire application, for example, and this is not a viable foundation for DevSecOps. A modular approach to writing code allows you to easily bake in critical security measures from the get-go and amend the code when necessary for continuous improvement.

Never forget that tack-on elements like firewalls or antivirus software are only backup measures — you should not and cannot ever rely on them as your only defense! Security by design is about implementing a risk-based approach to development that focuses on continuous assessment, analysis, improvement, and validation to create safer practices and better safety nets. Think of high-quality code as a moat and drawbridge, and the tack-on elements like your foot soldiers. If your moat and drawbridge are in good standing order, you should only require your army in true emergency situations.

Privacy
It’s crucial to understand that security by design also entails privacy by design. With regulations like the EU’s General Data Protection Regulation (GDPR) making headlines recently, lawmakers are finally enacting policies that affect technology use under the context of privacy. Your organization’s security strategy should take into account the compliance requirements and laws that apply to you, and put processes in place — e.g, controls — for verification and validation of compliance.

Of course, different types of data will require different types and levels of protection, whether technical, physical, administrative, or all of the above. Organizations should know the laws and regulations governing the type or types of data they specifically deal with. If GDPR applies to your organization, for instance, you would appoint a dedicated data protection officer, create a detailed data map, implement continuous monitoring, etc. And remember that a proper privacy plan always accounts for the worst, so you’ll need an action plan for recording, tracking, and reporting all privacy data complaints, incidents, and breaches in a timely fashion. 

Predictability
Another major part of good security is predictability, and a new model of dynamic data systems via analytics-driven security incident and event management (SIEM) platforms is filling in the gaps. Static data only allow teams to make slow, reactive, and manual decisions; they need a simple way to correlate critical information across all security-related data to maintain and manage their security posture.

Rather than merely watching events after they occur, your organization should be equipped to anticipate their occurrence and rapidly implement measures to limit their vulnerability in real time. Modern SIEMs offer invaluable, contextualized threat intelligence — whether external or internal — to minimize or even avoid the damage from major incidents.

While SIEM systems have largely been thought of as security tools for intrusion detection, a sophisticated SIEM can actually act as the nerve center for monitoring within an organization. Alongside real-time communications and targeted notification delivery, using a SIEM system to monitor change management and automating pipelines for development is an excellent way to achieve the situational awareness needed in a DevSecOps environment.

People
And finally, we can’t forget the people component. Creating a culture conducive to successful DevSecOps practices involves awareness, training, and full immersion. Know the privacy rules that affect your organization and enforce them through regular training sessions. Implement the right tools and processes and build toolchains that bring structure and standardization to collaboration within and between teams.

Unlike the bureaucracy of traditional security approaches, DevSecOps is a cooperative method that distributes the burden of security more evenly. The organization can operate more nimbly and with less friction and improve its handling of security issues on the whole. Finding success with DevSecOps may seem like a daunting challenge, but just remember that it all starts with gradual, piecewise changes and improvements at the ground floor of your organization’s security practices.

Related Content:

• 7 Ways to Maximize Your Security Dollars
• A Secure Development Approach Pays Off
• Why Security-Driven Companies Are More Successful

 

Black Hat Asia returns to Singapore with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier solutions and service providers in the Business Hall. Click for information on the conference and to register.

Robert Hawk is Privacy Security Lead at xMatters. He has extensive experience in information systems security, computer security, cybersecurity, information assurance, as well as governance, risk, and compliance (GRC) management. He specializes in frameworks and standards … View Full Bio

Article source: https://www.darkreading.com/endpoint/devsecops-the-importance-of-building-security-from-the-beginning/a/d-id/1331210?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

A close analysis of the code that took down part of the 2018 Winter Olympics computer network reveals a cunning plan to seemingly falsely pin the blame on North Korea.

On the first day of the games in Pyeongchang, South Korea, the main website crashed, Wi-Fi networks around the events became unusable, and data was wiped from servers by malware later dubbed Olympic Destroyer. IT security outfits had warned of a cyber-assault looming before the event, after a phishing campaign was spotted, and the attack was beaten off rather quickly.

In the weeks that followed, several analyses suggested that the attack was the work of the North Korean state-sponsored hacking team known as the Lazarus Group. However, a study by Kaspersky Lab engineers suggests that Lazarus didn’t write the code, despite appearances to the contrary.

Vitaly Kamluk, head of the APAC research team at Kaspersky Lab, told the antivirus biz’s Security Analysts Summit this week that the misattribution was understandable. The data wiping part of Olympic Destroy looks, at first glance, exactly the same as the Lazarus Group wiper used in the Bluenoroff malware responsible for the $81m cyber-heist against the Central Bank of Bangladesh last year – even down to the header.

“We can say with 100 per cent confidence that the attribution to Lazarus is false,” he said.

But the wiper function’s Rich header, which contains some metadata, included hints to the development environment the code was written in. The Olympic Destroyer code showed it was developed using Visual Studio 10 and made to look as though the code was the same as the C++-written Bluenoroff.

“The only reasonable conclusion that can be made is that the Rich header in the wiper was deliberately copied from the Bluenoroff samples; it is a fake and has no connection with the contents of the binary,” Kaspersky’s technical report on the matter states.

“It is not possible to completely understand the motives of this action, but we know for sure that the creators of Olympic Destroyer intentionally modified their product to resemble the Bluenoroff samples produced by the Lazarus group.”

So who did write the code? Kamluk said he didn’t know for sure, but that some of the methods of propagation and the VPNs used in the attack could link it to the Russian state-sponsored APT28 group.

Costin Raiu, Kaspersky’s director of global research and analysis, warned the conference that attribution is going to get tricky in the next couple of years. Security firms are building code databases that could automate the attribution of malware samples, but at the same time coders are getting smarter and we could see similar false flag operations in the future. ®

Sponsored:
Minds Mastering Machines – Call for papers now open

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/03/08/analysis_suggests_norks_not_behind_olympic_destroyer_malware_attack/