Intent in Action

Safeguarding our users' information and data is our top priority. We understand that despite our best efforts, security vulnerabilities can still emerge in places that we may not have been initially responsible for. That's why we highly value the role of ethical hackers, bug hunters, and professional security researchers in identifying and reporting such vulnerabilities.

This policy outlines our comprehensive approach to receiving, evaluating, and promptly addressing security vulnerability reports, while fostering collaboration with the security community to effectively tackle any issues that may arise.

I've found a vulnerability, how do I report it to you?

If you believe you've found a bug or vulnerability in a BeeHive software, web-app, or the website itself, we ask that you report it to us ASAP, no Rocky.

To do so, start a conversation via chat (that magical yellow bubble that appears in the corner of all our services) and let support know as much detail as possible about the vulnerability, including step-by-step instructions on how to reproduce it and any additional information that may aid us in comprehending and resolving the issue. You don't need to tell us where you are, or how you got there, that information is fetched automatically when a report ticket is created.

We have no "specific required format" for these reports, we simply ask you apply all possible brain cells when trying to communicate to us how and where something is broken. We are incredibly transparent and honest about report quality. If you expect public acknowledgement, you better deliver to us a report worth said acknowledgement. You will get no free research clout for throwing a half-assed report our way; you will make more work for us, potentially for nothing, and naturally that'll be held against you. We have yet to need to block anyone's ability to communicate with us over poor quality reporting; let's keep it that way.

We ask that you refrain from disclosing any information regarding the vulnerability to anyone other than BeeHive until we have had sufficient time to address the matter.

In the event that you choose to disclose it, we reserve the right to withhold any requested compensation if we determine that your means, manner, or method of public disclosure was done in bad faith.

Within 24 hours of receiving your report, we will acknowledge its receipt and provide you with an estimated timeline for when you can expect a more detailed response.

How does BeeHive handle vulnerabilities when I report them?

Upon receiving a report about a security vulnerability, we will promptly assess its validity and severity. If we determine that the report is indeed valid, we will take immediate action to address the vulnerability.

Throughout the process, we will keep you informed and provide regular updates on the status of the issue. Should we require any additional information or assistance from you, we will reach out to you directly. When submitting reports to us, our chat agent will store a cookie in your browser, to help us remember your report when you return to our site. If you clear your cookies after opening a disclosure, while we will still be sent your disclosure, we won't be able to talk to you about it without a pre-existing BeeHive service line.

Our team will diligently work on providing a solution for the vulnerability and thoroughly test it before implementing it on our website, web-app, or software pack. Once the fix has been deployed, we will (if we still can) notify you of the resolution, prompt you to re-test to confirm your submission has been fixed, and, with your consent, may even credit you for your invaluable assistance in identifying and reporting the vulnerability.

What's the "legal shtuff" about this policy?

We take the utmost care in upholding the confidentiality and privacy of the information you share with us. Rest assured that we will not disclose your identity or any details of the vulnerability report without your explicit consent, unless required by law.

If we are placed in a situation where we're required to render your information attached to a vulnerability report to law enforcement, we will canary to you immediately following unless prevented by duress.

Furthermore, we require that you adhere to all applicable laws and regulations when reporting any security vulnerability. It is important to refrain from engaging in any activities that may disrupt, damage, or compromise our systems or the data of our valued users.

And what all do these rules apply to?

This policy specifically pertains to the beehive.systems website and its associated services, web-apps, and software stack.

Why are you scanning me?

Short Answer: because we're being helpful to the greater good of CyberSecurity. 

CyberSecurity evolves and devolves in what is near real-time. Threat actors carry out attacks at all different times of day, different intervals - it's an infinite variable. Part of our operations to counter that, is building and maintaining an internal intelligence resource of what we can only summarize as "internet happenings".

Tasked by team members, our intelligence platform sweeps websites, domain names, and IP Addresses, looking for indicators of vulnerability or compromise, and alerts our Security Operations Center when vulnerabilities of certain measures are detected.

If you spot us "in-the-wild" hunting in your CyberSpace, it'll be by a User-Agent similar to:

Mozilla/5.0 (compatible BeeHiveNetworkScanner/1.0
+https://beehive.systems/scanner)

If you see this in your web server's logs, or your WAF, no need to panic, you're not under malicious attack.

What are you looking for?

Short Answer: development and security oopsies

We're hunting for anything from unauthenticated login pages, to default credential rights, to misconfigured or exposed storage buckets, to DNS misconfigurations (because it's always DNS somehow), to credential leaks and internal information disclosures, ongoing C2's and embedded infections, etc...in a way, we're simulating an APT attack cycle against your posture to better understand, and alert you if need-be, how you could potentially be vulnerable, while also being a remote defender in the event someone's ended up in your systems before us.

What if you detect a vulnerability?

Short Answer: We'll tell you, you can trust in that. We can't always promise you'll like how we do it. 

If we detect a specific class of malware running on an endpoint, you'll be alerted and given a threat report. How you choose to remediate is up to you, it's not as if it's in our abilities to turn back time.

If we detect live vulnerabilities that our team triages as "High Risk" or "Critical Risk", we'll make multiple attempts to contact any or all responsible parties, including by phone, email, or mail. If your organization participates with a HackerOne Disclosure Program, we'll bypass that riffraff and automatically submit it for triage to your organization's HackerOne.

Once disclosed, we'll share a Notification of Disclosure on our Writing Center, which will include information about the class and severity of the vulnerabilities disclosed, along with the "report" disclosure window. Once this window expires, we will disclose the full report including the vulnerability, impact, and additional information related.

These notices of disclosure serve for transparent public record, should the website, service, or business ever suffer from a breach connected to said vulnerability that causes customer loss.

Would you mind not scanning me/hunting in my infra?

Actually yes, we would mind. This is the entire concept behind a Zero Trust Security-in-Action Model, that unfortunately for everybody's sake, you're stuck dealing with. 

Let's think, why would you not wish for your domain to be scanned...

• Do you have private information or documents exposed? You shouldn't.
• Do you have out-of-date systems? You shouldn't.
• Oh, you're using another security provider? That's great; they miss threats too.
• Is it creating excessive load on resources? Looks like you should anticipate adding load balancing.

Any reason that you can come up with for why you'd prefer to not have your internet airspace scanned, we'll reply in kind with 5 reasons why it's not ceasing. You get free things out of this; let's not get wires crossed; but you also don't get to "blind" others to if/when you make a technological mistake. You make the oopsie, you fix the oopsie, we peacefully shake hands at the end of it, and such is the cycle.

There's no purpose in complaining about your "exterior perimeter" being looked at, per say. If you saw a potential intruder doing the same, how would you address it without the intruder offering you an "abuse" route? If you have a resource exposed to the open Internet, there is no point in complaining about this. Your true attacker doesn't accept abuse reports; in this case, we do not either. In your defensive considerations, however, we provide an "attacker at the door" for you to craft a response posture to. So, rather than being mad, you should go do that. What's your gameplan when it's not a "friendly" doing this? 

Are you actively in my system(s)/endpoint(s)?

Are we? We could be...one could never be personally sure. You might want to evict us if we are and you don't expect us to be. Go hunt; needing to ask this is a bad sign.