This post was authored by distinguished Advanced Security engineer, Chip Webb

Anti-virus software has traditionally used a blacklist approach. This means that the anti-virus (AV) software examines programs before they are run for “signatures” – bits of code – that are known to be associated with malware. If a program contains a signature indicating malware the AV package does not allow the program to run. In other words, any software that is determined to be in the signature list is not allowed to run. All other software is allowed to run. The signature list is the blacklist.

More recently some anti-virus software packages take the converse approach, called whitelisting. A whitelist AV package examines each program before it runs and if the program is determined to be in a list of known good programs it is allowed to run. All other programs are not allowed to run.

These two approaches require different management approaches. Blacklist AV packages require that their signature list be updated periodically to recognize newly developed malware. Whitelist AV packages require that a list of software packages that are allowed be created. In addition to lists, many whitelist programs support rules. A common rule is to allow software packages that are digitally signed by particular software publishers. If a software package complies with the rule set or it is in the list of known good packages it is allowed to execute.

iDRAC prevents foreign software from running in a whitelist manner. iDRAC firmware is packaged as a single binary “blob”. Only software in that blob is allowed to run. The whitelist is simply the single rule: only software in the blob can run.

An attacker might attempt to circumvent this rule by creating “rogue firmware” that looks like genuine Dell published firmware, but in fact contains malicious code.

Several best practices will prevent the introduction of rogue firmware on the iDRAC:

  • Only obtain iDRAC firmware from Dell
  • Store the firmware in a place with restricted access
  • Only allow a firmware update to be initiated by an authorized user
  • Require that the authorized user only use a firmware package that was stored in the place with restricted access

Note the following exceptions:

  • a malicious administrator could flash a rogue firmware
  • an administrator could be the victim of social engineering and be fooled into updating with non-authentic firmware
  • an administrator could have his credentials compromised

Of course all three of these exceptions are not unique to iDRAC and underscore the importance of the human factor in maintaining good security.

To account for these exceptions and further enhance security, iDRAC7 (present in Dell PowerEdge 12th Generation servers) improves upon previous iDRAC versions by requiring that the firmware image also be digitally signed, robustly ensuring that even in the face of the three exceptions noted above, iDRAC7 will reject unauthorized firmware. Thanks to the design factors discussed above, iDRAC is highly resistant to the kinds of viruses and malware that are typically seen on PCs and industry standard servers.

To learn more about the Dell Remote Access Controller, visit