Challenging Security Limitations: White vs. Black Box Testing & Real Risk

I awoke in the middle of the night. It was the witching hour, 3am! Rapidly behind my lowered eyelids pie-graphs and charts explaining esoteric security concepts flashed in sequence, but I was too groggy to retain everything I learned. Why I am chosen for this sort of lucidity, I will never understand. This article is an attempt to best re-create the deeper concepts I received in that vision, but a week has elapsed since that night and therefore I have mostly forgotten everything. I’ll just have to wing it.

White Box Vs. Black Box

The article I have linked above describes the difference between the security, and/or software testing procedure in which internal elements are either known or unknown by the testers. The benefits of knowing the internal workings in a test allow for a more thorough and rigorous approach to each and every individual node or aspect of the subject, whereas a Redteam performing an unknown or Black Box test may not strike upon every single nuance built into the system, but may however come up with something heretofore unknown. The Black Box test is conducted exclusively by third-party security or testing professionals, which is requisite due to their specific insights into security penetration and access. For these reasons, it is considered a “low-level” test which is also known as an integration or unit test. It is conducted, in other words, from the outside working inward.

White Box tests are conducted usually by software developers or some part of the internal staff working on the project or overview. White Box tests are considered high-level tests also called system or acceptance testing. These tests are intended to fully air-tight the system after the beta-testing bugs have been detected and eliminated. The benefits of thorough White Box testing are thoroughness, insofar as the team knows the way the program or plan “should” work and can therefore test against this ideal. An internal team conducting this type of test knows the code (or building scheme; what have you), and therefore possesses an eagle-eye’s view of the entirety of the subject’s workings.

So Which Is Better For Your Company?

Before I answer this question for you, ask yourself:

1. Do I have an internal team already providing White Box testing?
2. Are they specifically hired for testing, or did we just divert Sheila and Burt from engineering over there to do another bug-sweep? (Remember what happened in the 1986 film Aliens.)
3. If you have a specific internal team for testing, are they getting on well with engineering? Do they have a working rapport and are able to comprehend each other effectively leading up to the testing phase?
4. Did you seek professional consulting from a specialized security Redteam?
5. If you did not answer ‘YES’ to each of the above questions, you and your company are not necessarily ready for what I am about to reveal to you in the next section.

Attrition Theory

I am not a mathematician however I think you can get behind me on this.

x/a – y/b = (+, – = successful, unsuccessful)

Attrition Theory basically asserts that given company a with resources x (personnel, training level, security architecture, security equipment, surveillance, etc.) when attacked by competitor (or OpFor) b with resources y, a simple subtraction is necessary to determine who is successful in the attack. If the OpFor b is willing to invest enough time and resources into their raid on company a, their success will be indicated by the result being a negative number, having taken the amount of invested resources from company a into the red.

Is your company ready for your competitor or OpFor to outbid you on your willingness to invest in preventative security measures? Following a breach, it may be too late to save face so insurance, or the ability to clean up after the fact, is just not going to be enough.

Now to answer the question I asked before: Which sort of test is better?

Chew On This

So your internal team designated another internal team to do the testing. Ok. So the engineers got with the testers and did a Power Point powwow. Sure. So then after that you decided you still thought it would be wise to get an outside team to consult. Good. They do their scans and don’t really provide any insight beyond the scope of the White Box team, but good on you for checking. So you’re awesome, right? Invulnerable!

BRIQ | HAUS LTD. SECURITY & INTELLIGENCE has the guts to ask you these hard questions:

1. How secure is your facility/program in case of a fire drill? Do you have protocols in place to handle securing end-user’s data BEFORE they flee the scene?
2. What about in case of a REAL FIRE. And are you willing to test this in a non-drill scenario to absolutely ensure your security protocols work?
3. Is your staff alerted to the higher danger of active shooters, like the scenario recently at YouTube? If so, do you again have a plan in place to protect end-user data from a potential shooter or *gasp* terrorist attack?
4. What about acts of God like locusts, plague, or you know, floods? Are you guys going to not only get out of the building safe, but will you be able to stop Boris & Natasha from killing Moose’n’Squirrel during the disaster? For the OpFor, luck is when preparedness meets opportunity.
5. If you didn’t answer ‘YES’ to each of the above questions, you need to contact us at BRIQ | HAUS LTD. SECURITY & INTELLIGENCE and immediately schedule consultation. Our information technology and intelligence community professionals know things that can protect your bottom line, so you can stop worrying about all the hard realisms I just threw at you.

My name is Robert Brooks Authement, owner and operator of Briq Haus Ltd. I think like the bad guys so you and your team don’t have to. If you think these insights can be of assistance to you and your company, please consider me and my team at your service.