Functionality vs Security - security assurance methodology
jrey at linux.ibm.com
Fri Feb 14 08:09:36 AEDT 2020
On 2/13/20 10:36 AM, Brad Bishop wrote:
>> On Feb 13, 2020, at 3:15 AM, Mihm, James <james.mihm at intel.com> wrote:
>> Exposing the REST D-Bus APIs via a network interface is bad practice and should be disabled by default.
> Yeah. You are right of course. It isn’t really the what that bothers me here it is the how. I’m disappointed that Intel was only able to make the Redfish enabled webui work for Intel and not anyone else.
>> Just because it was done that way in the beginning doesn’t mean that it should remain that way.
> I don’t remember saying this?
>> Applications should be configured to be secure by default.
> This sounds perfectly reasonable of course but I don’t know how to implement it for OpenBMC. I’m not even sure what it means. Security isn’t a boolean it is a spectrum. Show me any security posture, and I will show you one that is slightly more strict/secure. Clearly, my security posture isn’t strict enough for Intel. However I know there are organizations out there that have even stricter security postures than Intel. So in the general case - how does one decide which posture should be the default, and when is ok to “break” existing usage patterns rather than “update” them for the sake of a stricter security posture? Help me establish some rules so we can avoid this kind of bickering in the future.
Thanks for that introduction. We're working on a way to answer
questions like this in the [OpenBMC security assurance workflow] which
promises to address all security items using world-class practices.
Yes, literally all security items. There are some excellent references
out there that we are trying to use. (footnote1)
For example, a key point in the Cloud Security Industry Summit > "[CSIS
Secure Firmware Development Best Practices]" > "BMC" section is to
"Document all available interfaces" specifically including Redfish
APIs. A security review would find the D-Bus APIs, and raise suspicion.
Most security assurance methodologies begin with an architectural review
of the system and drill down to all external interfaces. We need that
for OpenBMC. The hard part is getting the right level of abstraction
because the use cases and details are different, so nothing is merged
yet. The current attempt (in review),
[architecture/interface-overview], describes how BMCWeb serves REST
APIs (which includes the D-Bus APIs). I hope we can merge this as a
simplified view of the BMC's primary interfaces.
Anyway, that's how I see the security story playing out for OpenBMC ...
using OpenBMC security assurance workflow as the way to organize all
OpenBMC security documentation and talk about which pieces are
relatively more important. When these docs are ready, we can refer to
them as we continue to bicker and argue in a more sophisticated way.
P.S. I gave my opinion about the D-Bus APIs in a separate email,
(footnote1): Don't expect any miracles though, because following the
security assurance methodology is a lot of difficult work and requires
cooperation between folks in different disciplines. And we're just
getting started. And all the big words makes peoples' brains hurt.
[OpenBMC security assurance workflow]:
[CSIS Secure Firmware Development Best Practices]:
More information about the openbmc