Security Saturday!
A late post this time, for reasons. Let's talk a little about black box debugging.
In actuality this is on my mind because a member of the Rubin Report community (six tenths) asked a question about Youtube/Google. The idea was to be able to discern if something changed on his side, Google's side or something simply went wrong.
Black box debugging is when you have no access to the guts of the system you are trying to debug. You are simply throwing interactions at the system in the hope of gleaning more information or finding alternate ways to accomplish your goal.
Now regular programmers, software architects and other developer type people will experience this when talking to some API that someone set up without correct documentation. Personally I used to be a software engineer in retail, where I had to talk to the APIs of several resellers/webshops. One of them used XML for their API according to their documentation. However, I could not get any correct response from that API. After a day of black box debugging I found out that the whole API used XML, EXCEPT the login functionality, which in practice only accepted JSON post data!
Now, how does one go about black box testing and how does one find out what went wrong.
First establish what you would expect to happen, and the steps you and the system (black box) should be taking to reach that desired ending state. In the example above, I need to send a request and I expect a verification token back. The steps involved are the message headers, the message (POST) body and the information contained in the body.
And then you vary over all of the adjustable parameters involved in your process (using something like postman, for example https://www.postman.com/).
What this has to do with security? A lot, since a lot of hackers will similarly treat your application as a black box, and throw parameters at it. So one way to test if your application is secure, is treating it as a black box. Then make your goal to have the application behave in a way that is harmful (a simple crash is already harmful, so do not think too deeply about hollywood-level hacking :P)
On a side-note, I noticed that the security guest lecture I did was not for security 101, but for security 102 (at least, if I understand these numbers correctly, it is Security 2 for Dutch students). So I will venture out to first try a small Security 101 series first.
This should also give me some time to sort out my abysmal recording device situation. I finally will be getting my paycheck, so I can replace my main laptop (with a desktop this time, for cost efficiency) and then if there is money left, I will be getting some neat mic. I have been wanting to upgrade for years but some other things always had priority.
As always, stay safe out there.
There is so much more to this one chapter, but it is so good already!
I had to cut it short because guests arrived, but this should get you started on your own study :)
@calvinrempel Thank you once again for the Theology Tuesday you did, I refer back to it in this one :)
@JamesDerian Congratulations with your Marriage :)
Next time there might (almost certainly) not be a Theology Tuesday, so the official next one will be February 22nd! I have a marriage to attend. As the groom. Our home is still half a project.
Fun times!
Alc and I talk about my book that is now officially finished. This is part 1 of 2. Parts have not been neatly cut. Part two will air 5 minutes after part 1 for coninuity!
Hope you enjoy :)
This is the third corner to have persistent discussions and talks in. I love tech, but especially once it transcends hardware a little. I have two degrees; a bachelor's in Software Engineering and a master's in Information Security Technology. My graduation thesis focused on assembly-level optimizations (that is, one level above the hardware level) and my free subjects were in formal verification. This is why I love programming in the security corner, or maybe it is the other way around.
I started going down the Security path because I early on saw that the world around us would become a dangerous cesspool of badly-implemented and hostile tech. Now I am one of the people that understands the field around that mess :)
So in here you can discuss secure phones, weird programming languages, sad truths about internet-connected fridges. Also about malware, adblockers, and so on and so fort!
A lot of tech talk I do over at the @Lunduke community, where a lot of nerds hang out and it is ...
Much like the reading corner, let's have a music corner! A few rules for this one, since some music can be provocative. I don't mind much but let's keep youtube links with risque thumbnails out of here.
Other music I might also mind. "Do you find that offensive?" might someone ask. Yes, there is some music I choose not to listen on principle, and I walk a thin line there sometimes. But do not worry, I have a wide taste otherwise so feel free to share almost anything :)
Either way, here is the music corner!
Many times when we talk about security, we mean to say "Digital security". In essence we mean to say that our hardware and software that we use stays safe no matter what we do. And even though the ISO27001 standard (and by extension, for example, the NEN7510 standard) make it abundantly clear that security is a people-domain problem, we usually take that as a process-like truth. Meaning, we think that being secure is a matter of regulating people.
The truth is very different. For example, while writing this I am pretty shot. I slept five hours and I an under influence of a bunch of painkillers and some alcohol. Before you ask what I was thinking, let me mention that I have a genetic defect in my spine that I am dealing with right now by taking measured doses of all three (and yes, to get the Bible into this conversation, there is even a biblical ground for the inebriation with alcohol - see proverbs and the letters to Timothy - , although I did not use red wine. But hey, I am still on top of ...
