First thing you have to decide is if you think it is important to distinguish (at least in certain cases) between empty strings and NULL in your business layer (BL), or not. I have seen systems where this difference was important, and other systems where the whole DB or its API was configured not to distinguish between those cases, because in the BL it made no difference. So before asking on which layer a mapping shall take place, clarify what you want to use here.
If you need to distinguish NULL/undef from the empty string in your BL, then the answer is simple: don't do any automatic replacement. Map the empty string to an empty string, and "undef" to NULL (and vice versa). You have to write your business code so it can deal correctly with empty strings and "undef"ined values as well.
If you want to treat "undef" and "empty string" as equal in your BL for all tables and attributes, then it clearly makes sense to let the ORM do the mapping. If, however, you want this only sometimes, for some columns, and in other cases you need to distinguish between both values, you need to know how often you expect this situation. If the former is a rare situation you need only for approximately a half dozen attributes, you can implement the behaviour in the BL on a "by case" basis. If you have 100 or more attributes for which "undef" and "empty string" should be treated as equal, you should extend your ORM to let it handle this for certain columns in a generic manner.
For example: for certain, specificially tagged columns, the ORM could just map any NULL value to an empty string when it reads the data from the DB, and convert the empty string back to NULL when it writes the data again. Extending your ORM in this manner to provide a generic mechnanism will probably need some effort, and you have to decide if you can reuse this mechanism often enough to gain more benefit from it than the effort it takes to implement it.