Earnest Engineer

  In many healthcare applications, often due to the cloistered nature of the use cases – e.g. it will only be accessed by users authorized in a particular facility, such as an operating room suite – the needs for Authentication and Authorization are minimized when the system is designed and implemented. This presents a risk as soon as you allow for the possibility of users with ill-intent or that otherwise want to operate outside their given roles. Custom applications need to consider these possibilities and implement the following measure to ensure the integrity of the system. 1.   Authentication and Authorization Controls: Multi-Factor Authentication (MFA): Implement MFA for all user logins. This adds an extra layer of security beyond just a username and password. Role-Based Access Control (RBAC): Grant users access only to the data and functionalities they need for their specific role. This minimizes the potential for unauthorized access. Strong Password Policies: ...

 This is mostly a compilation for my own reference, but sharing makes sure I can find it more easily and perhaps I'll pick up some comments for additional hints! https://code-maze.com/csharp-tips-improve-quality-performance/

  A common problem on the Common Weaknesses list is CWE-862: Missing Authorization . This happens when a product doesn't check a user's permissions before they access something. Often this weakness is solved once you implement an access control system. This system typically asks users for their login information when they open the application. This is like securing the "front door" - you know who's coming in. At that point you may have solved the “Front Door” authentication problem, where you know who you are letting in. But what about inside the application? Each resource (like data or features) should also be checked against the user's permissions. This is the “Authorization” problem. This is a critical design consideration for any application because it applies to everything from buttons on the user interface (UI) to internal parts (libraries) used by the application. The importance of these checks depends on how sensitive the application's informat...

 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...

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...

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).