Skip to main content

Posts

Looking at cybersecurity from the other side of the looking glass

 Understanding malware As a software engineer, I have taken for granted I'd understand a lot of how malware works. But then I also know that the devil is in the details. This lead me to a YouTube series by @lauriewired ( https://www.youtube.com/@lauriewired ), who is a reverse engineer and takes apart malware in full view so that viewers understand process as well as tools.  She is thorough and methodical in her videos, which makes me self-conscious about the way I leapt off the trail when doing similar investigations and looked to see what was at the endpoints or URLs I found in code - without finishing to see conclusively what the goal of the malware was. I'd assume data exfiltration, without necessarily proving such and from watching @lauriewired, I see there are many variants and what I'd missed was seeing how the perpetrators were likely actually setting up to download an entire command and control piece to make a virtual slave out of the system. Seeing malware de-obfu
Recent posts

Cybersecurity

Cybersecurity It's for the web? Yes . It's for applications? Yes . It's for mobile? Yes . It's all code, anywhere, all the time.   But how do I understand how to secure such different codebases and platforms? I've said it before and I'll say it again: OWASP . They have a compendium of cheat sheets to help you on your path. These are goldmines of direct actions you can take for better security when coding across platforms, toolsets, languages. I had forgotten how many morsels of immediately accessible techniques the cheat sheet series  each contains. For instance, Session Stealing is one of the vectors through which the Solar Winds hack was accomplished. Reduce the time period a session can be stolen in by reducing session timeout and removing sliding expiration. But how? Here's one .Net example, which makes it concrete: ExpireTimeSpan = TimeSpan.FromMinutes(60), SlidingExpiration = false OWASP is not just Top-10 lists and the place to find out about the l
Note to self:  Don't write your own encryption. Just. Don't.  There are already capable, tested and even tried an true encryption algorithms. Implemented across platforms and languages and built into libraries and services. And did I mention " Tested "? With mathematical validations of how hard they should be to crack?  If you actually need to encrypt things, then use existing algorithms and software to actually encrypt things. You'll have enough to worry about with key management, library verifications and making sure the rest of the team gets up to speed that, no, it's not just Easier | Faster | Better to do it yourself. Unless of course your sole job is creating, writing, testing, proving and implementing encryption algorithms, because you have all the maths...

Designing for Security

Ideally, thinking of security at the start of a project will mean more hard decisions and discussions and work up front, but a better implementation and product in the end. Like so much of software engineering, it's a team sport and an infrequently included group in security discussions are the designers, like the folks doing Human Centered Design (HCD or UCD), User Experience (UX) or whomever in your world takes care of designing the parts of the system the users touch. They can help a lot with designing security into a product and setting a cyber security mindset. The article on linked in ( https://www.linkedin.com/pulse/designing-security-lindsay-morsillo/ ) looks at this in more detail (7-10 minutes to read).

Unit Testing - What to Test

This I wrote to answer a question that came up when we were discussing our software process and I was training developers on how to unit test. It seems a simple enough question, but I kept pondering it and delving deeper until I realized I needed to write this monograph. What unit tests should we write? How do we know what to test? Ideally, unit tests should cover every path through the code. It should be your chance to see every path through your code works as expected and as needed. If you are practicing Test Driven Development then it's implied everything gets a test. In the real world, you might not be allowed to test everything - for instance, if the testing suite ends up taking a week to run, then the world will have changed by the time it finishes and the test results will be obsolete. Unit testing at it's basic is testing an object, a method - the smallest unit of your code that it can test independently. It should test the inputs "goes into" an

Encryption - practicum

Encryption Primer When we specify that things need to be encrypted, it usually means we need to keep those things secret. Encryption in this sense encompasses all the ways to protect information, including public key encryption, cryptographic hashing, digital signatures as well as all the things that support it such as security certificates and key management. Working in a React Native, NodeJS/NPM, JS/ES6 environment, there are many more things to think about than simply calling the OS encryption library and feeling pretty good that's handled. This page is meant to list the available options, applicability to various tasks and the supporting infrastructure required when you need to encrypt meaningful data. An important criteria in evaluating a crypto library is any validation or approval from a standards body. Anybody can implement and publish a npm crypto library, implementing standard cryptographic algorithms - but there is no guarantee with most that they a