• 1 Post
  • 51 Comments
Joined 2 years ago
cake
Cake day: July 2nd, 2023

help-circle






  • It’s the capability of a program to “reflect” upon itself, I.E. to inspect and understand its own code.

    As an example, In C# you can write a class…

    public class MyClass
    {
        public void MyMethod()
        {
            ...
        }
    }
    

    …and you can create an instance of it, and use it, like this…

    var myClass = new MyClass();
    myClass.MyMethod();
    

    Simple enough, nothing we haven’t all seen before.

    But you can do the same thing with reflection, as such…

    var type = System.Reflection.Assembly.GetExecutingAssembly()
        .GetType("MyClass");
    
    var constructor = type.GetConstructor(Array.Empty<Type>());
    
    var instance = constructor.Invoke(Array.Empty<Object>());
    
    var method = type.GetMethod("MyMethod");
    
    var delegate = method.CreateDelegate(typeof(Action), instance);
    
    delegate.DynamicInvoke(Array.Empty<object>());
    

    Obnoxious and verbose and tossing basically all type safety out the window, but it does enable some pretty crazy interesting things. Like self-discovery and dynamic loading of plugins, or self-configuration of apps. Also often useful when messing with generics. I could dig up some practical use-cases, if you’re curious.








  • Generally speaking, fault protection schemes need only account for one fault at a time, unless you’re a really large business, or some other entity with extra-stringent data protection requirements.

    RAID protects against drive failure faults. Backups protect against drive failure faults as well, but also things like accidental deletions or overwrites of data.

    In order for RAID on backups to make sense, when you already have RAID on your main storage, you’d have to consider drive failures and other data loss to be likely to occur simultaneously. I.E. RAID on your backups only protects you from drive failure occurring WHILE you’re trying to restore a backup. Or maybe more generally, WHILE that backup is in use, say, if you have a legal requirement that you must keep a history of all your data for X years or something (I would argue data like this shouldn’t be classified as backups, though).





  • I would be wary of using STIGs as a reference point for good security practices. They are notorious for being poorly-enforced in the real world, and it stems from the fact that they are written too ambiguously. Getting STIG reviewed can have wildly different results just depending on the reviewer’s interpretation of the written text. I’ve seen this first-hand in my job, where we’ve gotten dinged on specific STIGS for code that hasn’t changed in a decade, just because a reviewer decided to interpret a STIG differently than others from the past. And trying to be pro-active about complying with STIG requirements ahead of time always boils down to arguments about “well, what does the STIG MEAN here?”