Earnest Engineer

The following is a story that I think highlights the assumptions that get you into trouble online... https://www.proofpoint.com/us/blog/threat-insight/i-knew-you-were-trouble-ta456-targets-defense-contractor-alluring-social-media This is particularly scary since we found so much utility in online connections during the pandemic and out of necessity, started trusting more online. Please note the timeline for this breach - it was a long, slow process, a key factor in many 'cons'. "Build trust" is a key first step, once someone has identified you as a party. You think...you're convinced you know who your talking to, but if you don't triangulate the identity with some non-online, ideally in-person information, you shouldn't trust. And even if you do get what seems like real-life confirmations of identity, you must look at questioning motives, needs, and keeping danger at arms-length. Online includes email, texting (sms), application chatbots, voice communicati

Examining the risks of IT hero culture This ISACA article examines a situation that is commonplace - since people often have an uneasy working relationship with technology, such that if one is able to help such a person out of a jam and save hours or more of work, for instance, then one is lauded as a hero in the eyes of the person saved.  This article presents how this model is sub-par, wearing on both the heroes and those counting on them, resulting in an unsustainable situation. This is directly related to the sorts of relationships that project and program managers have with cybersecurity: they bring in cybersecurity expertise to apply patches on-top of code and systems to perform 'cybersecurity' rather than making it a fundamental characteristic of the built system - from design through maintenance. Unfortunately we are in a time and world of persistent threats and supply chain vulnerabilities. Cybersecurity is an everyday, everybody, all-the-time activity, broken out of t

  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: Enforce s

 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