Edgescan, why we do what we do.....

 


The cyber security industry is full of solutions to make you more secure. Some are unproven and other approaches work if deployed properly. Our industry is very fragmented. for example a recent "Cyber Defense" award I noticed has 195 categories! 

I suppose we need to ask ourselves as companies from time to time why we do what we do? 

So, the following post is, I guess, the reason we developed Edgescan and why we believe its a decent solution to help organizations improve and be more resilient in relation to cyber security and system protection....


Vulnerability scanning alone did not work.

The idea of software testing software for vulnerabilities is a good one but both sides of the equation may have bugs. Bugs in one side (The target) may result in vulnerabilities, whilst bugs on the other side (Scanner) may result in false negatives and false positives. 

Accuracy: To that end we built edgescan as a combination of automation to discover vulnerabilities at scale but  when certain types of potential vulnerability are discovered it informs a human to validate and triage the issue. The result of this is to ensure we have no false positives and the discovered issues are risk rate appropriately.

Coverage: The human element of edgescan makes sure the assessments are getting the coverage they need to be successful. Even in functional unit or system testing when developing software 100% coverage is extremely hard to achieve. It requires following every logical flow of code in an application which could be hundreds or thousands of permutations. To make this challenge even more complex different technologies require different types of automation be they API's javascript-heavy frameworks or generic n-tier applications.


Splitting vulnerability management into Silos of network and application vulnerability intelligence is not intelligent.

When defending the enterprise we need full stack visibility. Why? "Hackers don't give a S*it". We need to understand what risks and blind spots are present and make sure we have nothing exposed which can be used against us.

Combining network, host and web application vulnerability in a single view provides this. Even better is its validated and provides a single source of truth. Full stack visibility provides the ability to prioritize mitigation across the entire tech stack rather than using different sources of vulnerability data from different providers.


Accuracy and "noise suppression" would help people move more efficiently and quickly

Most folks would agree, receiving a feed of accurate and triaged vulnerability intel helps make decisions very quickly. It helps with priority and answering the questions regarding "Which vulns should we fix today?" Removing false positives and appropriate or custom risk rating is what we call "Noise suppression" it cuts through the noise to help organizations be more effective. Also when vulnerability data is used to kick off an automated process it better be accurate!!!

Traditional penetration testing was not scalable and "clunky"

Traditional penetration testing requires contracts, is not immediate and results in a PDF as the output. It is slow, clunky and expensive. Delivering penetration testing via the same portal as vulnerability management allows you to go deep and get a complete picture. Having penetration testing via the portal provides the ability to retest mitigated vulnerabilities on demand also rather than waiting for a consultant and can be invoked via automation

Metrics and trending data is required for measuring improvement.

The idea of having a extensible platform with the ability to extract and view validated/accurate  vulnerability data on demand and integrate to any other ticketing or GRC system was important. This helps with vulnerability lifecycle management and development pipeline integration.

Bugbounties are good but are a compliance and GDPR risk and not very controllable.

Bug bounty platforms use NDAs to trade bounty hunter silence for the possibility of a payout. If this NDA is broken there is no real recourse. Suing a bounty hunter in a third world country wont pay your GDPR fine!!

Bug bounty platforms may violate California and federal labor law, and the EU’s General Data Protection Regulation (GDPR). - Your vulnerability data  (and possibly client PII is on random laptops of bounty hunters globally. no governance, possibly no encryption. Do your clients understand their data could be on a random hunters laptop in say Pakistan?

Good article here: https://www.csoonline.com/article/3535888/bug-bounty-platforms-buy-researcher-silence-violate-labor-laws-critics-say.html

Attack Surface Management (ASM) & API discovery is important

We built ASM and API discovery in 2017 believing visibility is super important. Being informed in real-time of exposures of rogue deployments as they happen is key to continuous resilience. We cant secure what we cant see.

More here: 

https://info.edgescan.com/hubfs/Datasheets/Attack%20Surface%20Management%20Datasheet.pdf 

https://www.edgescan.com/services/api-security-testing/

Support for technical staff is important

We decided to deliver support to  our clients. We don't expect our clients to be cyber security experts. Everyone in the Edgescan team is a seasoned penetration tester due to our internal rotation on a monthly basis of teams from Edgescan support to consultancy, SAST, Software security and stuff not suitable for a SaaS which our clients require.


Validator v False Positive


Be Safe,

- ek

 

Comments

Popular posts from this blog

20 years of Vulnerability Managment - Why we've failed and continue to do so.